lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <163306112497.261665.422355129148748890.b4-ty@mit.edu>
Date:   Fri,  1 Oct 2021 00:06:21 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     jack@...e.cz, yangerkun <yangerkun@...wei.com>
Cc:     "Theodore Ts'o" <tytso@....edu>, yukuai3@...wei.com,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: update last_pos for the case ext4_htree_fill_tree return fail

On Tue, 14 Sep 2021 19:14:15 +0800, yangerkun wrote:
> Or the ls for ext4 dir can run into a deadloop since info->last_pos !=
> ctx->pos which will reset the world and start read the entry which has
> already got before. Details see below:
> 
> 1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
>    leaf block which own the ext4_dir_entry_2
> 2. block 1 read ok and call_filldir which will fill the dirent and update
>    the ctx->pos
> 3. block 2 read fail, but we has already fill some dirent, so we will
>    return back to userspace will a positive return val(see ksys_getdents64)
> 4. the second ext4_dx_readdir will reset the world since info->last_pos
>    != ctx->pos, and will also init the curr_hash which pos to block 1
> 5. So we will read block1 too, and once block2 still read fail, we can
>    only fill one dirent because the hash of the entry in block1(besides
>    the last one) won't greater than curr_hash
> 6. this time, we forget update last_pos too since the read for block2
>    will fail, and since we has got the one entry, ksys_getdents64 can
>    return success
> 7. Latter we will trapped in a loop with step 4~6
> 
> [...]

I rewrote the patch summary and the first paragraph to improve the
English:

    ext4: fix potential infinite loop in ext4_dx_readdir()
    
    When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
    infinite loop since if info->last_pos != ctx->pos this will reset the
    directory scan and reread the failing entry.  For example:

Applied, thanks!

[1/1] ext4: update last_pos for the case ext4_htree_fill_tree return fail
      commit: 42cb447410d024e9d54139ae9c21ea132a8c384c

Best regards,
-- 
Theodore Ts'o <tytso@....edu>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ