linux-ext4 - Re: [PATCH] ext4: fix indirect punch hole corruption

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150205205601.GA5205@mew>
Date:	Thu, 5 Feb 2015 12:56:01 -0800
From:	Omar Sandoval <osandov@...ndov.com>
To:	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Lukáš Czerner <lczerner@...hat.com>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	Chris J Arges <chris.j.arges@...onical.com>
Subject: Re: [PATCH] ext4: fix indirect punch hole corruption

On Thu, Feb 05, 2015 at 12:50:13PM -0800, Omar Sandoval wrote:
> Commit 4f579ae7de56 (ext4: fix punch hole on files with indirect
> mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect
> mapping. However, the case where the punch happens within one level of
> indirection is incorrect. It assumes that the partial branches returned
> from ext4_find_shared will have the same depth, but this is not
> necessarily the case even when the offsets have the same depth. For
> example, if the last block occurs at the beginning of an indirect group
> (i.e., it has an offset of 0 at the end of the offsets array), then
> ext4_find_shared will return a shallower chain. So, let's handle the
> mismatch and clean up that case. Tested with generic/270, which no
> longer leads to an inconsistent filesystem like before.
> 
Ah, forgot to mention that this applies to v3.19-rc7. Additionally,
I've attached a script which reproduces the issue. You can run
xfs_io -c fiemap "$FILE" (after an umount/mount of the filesystem just
be safe) and see that before the fix, a bunch of blocks get swallowed:

/mnt/scratch/test:
        0: [0..31]: 1026..1057
        1: [32..127]: 930..1025
        2: [128..255]: 2114..2241
        3: [256..511]: 2306..2561
        4: [512..535]: 2818..2841
        5: [536..1559]: hole

... but after the fix, the hole is in the right place:

/mnt/scratch/test:
        0: [0..31]: 1026..1057
        1: [32..127]: 930..1025
        2: [128..255]: 2114..2241
        3: [256..511]: 2306..2561
        4: [512..791]: 2818..3097
        5: [792..1047]: hole
        6: [1048..1559]: 4122..4633

(These examples are from a 1k-block ext3 filesystem with
CONFIG_EXT4_USE_FOR_EXT23=y).

-- 
Omar

Download attachment "ext4punch.sh" of type "application/x-sh" (585 bytes)