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  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]
Date:   Tue, 13 Mar 2018 13:23:13 +0100
From:   Lukas Czerner <>
To:     Jayashree Mohan <>
        Vijaychidambaram Velayudhan Pillai <>,
        Ashlie Martinez <>
Subject: Re: Crash consistency bug in ext4 - interaction between delalloc and

On Mon, Mar 12, 2018 at 08:50:02PM -0500, Jayashree Mohan wrote:
> Hi,


thanks for the report.

> We've encountered what seems to be a crash consistency bug in
> ext4(kernel 4.15) due to the interaction between delayed allocated
> write and an unaligned fallocate(zero range). Say we create a disk
> image with known data and quick format it.
> 1. Now write 65K of data to a new file
> 2. Zero out a part of the above file using falloc_zero_range (60K+128)
> - (60K+128+4096) - an unaligned block
> 3. fsync the above file
> 4. Crash
> If we crash after the fsync, and allow reordering of the block IOs
> between two flush/fua commands using Crashmonkey[1], then we can end
> up zeroing the file range from (64K+128) to 65K, which should be
> untouched by the fallocate command. We expect this region to contain
> the  user written data in step 1 above.
> This workload was inspired from xfstest/generic_042, which tests for
> stale data exposure using aligned fallocate commands. It's worth
> noting that f2fs and btrfs passes our test clean - irrespective of the
> order of bios, user data is intact in these filesystems.
> To reproduce this bug using CrashMonkey, simply run :
> ./c_harness -f /dev/sda -d /dev/cow_ram0 -t ext4 -e 10240 -s 1000 -v
> tests/generic_042/

Hmm, I do not seem to be able to reproduce this problem. However I am
running in a virtual environment with Virtio disk so that might be the
problem ? Sorry if I am missing something it's my first time trying

Also it's not yet clear to me we can zeroout the entire block instead of
just a part of it because of the crash ? Unless it was actually zero
before we wrote to it, so isn't it lost write rather than zeroout ?

I think that comments from Dave are valid here as well I am not
necessarily sure how this situation can happen anyway. So maybe we do
have a bug there somewehere. I guess I'll know more once I am able to


> and take a look at the <timestamp>-generic_042_fzero_unaligned.log
> created in the build directory. This file has the list of block IOs
> issued during the workload and the permutation of bios that lead to
> this bug. You can also verify using blktrace that CrashMonkey only
> reorders bios between two barrier operations(thereby such a crash
> state could be encountered due to reordering blocks at the storage
> stack). Note that tools like dm-log-writes cannot capture this bug
> because this arises due to reordering blocks between barrier
> operations.
> This seems to a bug, as it is zeroing out user data that is ideally
> not supposed to be zeroed by the fallocate command.
> Let me know if I am missing some detail here.
> [1]
> Thanks,
> Jayashree Mohan

Powered by blists - more mailing lists