linux-ext4 - Re: [PATCH] ext4: fix unsafe extent initialization

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181210051037.GG1840@mit.edu>
Date:   Mon, 10 Dec 2018 00:10:37 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     "zhangyi (F)" <yi.zhang@...wei.com>
Cc:     linux-ext4@...r.kernel.org, miaoxie@...wei.com
Subject: Re: [PATCH] ext4: fix unsafe extent initialization

On Sat, Dec 08, 2018 at 10:25:58PM +0800, zhangyi (F) wrote:
> Current ext4 will call ext4_ext_convert_to_initialized() to split and
> initialize an unwritten extent if someone write something to it. It may
> also zeroout the nearby blocks and expand the split extent if the
> allocated extent is fully inside i_size or new_size. But it may lead to
> inode inconsistency when system crash or the power fails.
> 
> Consider the following case:
>  - Create an empty file and buffer write from block A to D (with delay
>    allocate). It will update the i_size to D.
>  - Zero range from part of block B to D. It will allocate an unwritten
>    extent from B to D.
>  - The write back worker write block B and initialize the unwritten
>    extent from B to D, and then update the i_disksize to B.
>  - System crash.
>  - Remount and fsck complain about the extent size exceeds the inode
>    size.
> 
> This patch add checking i_disksize and chose the small one between
> i_size to make sure it's safe to convert extent to initialized.
> 
> ---------------------
> 
> This problem can reproduce by xfstests generic/482 with fsstress seed
> 1544025012.

Hmm, your explanation is great and the patch makes sense.  I haven't
been able to reproduce the problem by adding -s 1544025012 to the
fsstress arguments.  This may be because fsstress being run with two
processes (-p 2) and the failure may be timing dependent?

How easily can you replicate the problem?

						- Ted