linux-ext4 - Re: [PATCH] ext4: Fix fdatasync(2) after extent manipulation operations

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: <20170529183027.ddn7o4jeck7urro7@thunk.org>
Date:   Mon, 29 May 2017 14:30:27 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-ext4@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] ext4: Fix fdatasync(2) after extent manipulation
 operations

On Thu, May 25, 2017 at 04:25:24PM +0200, Jan Kara wrote:
> Currently, extent manipulation operations such as hole punch, range
> zeroing, or extent shifting do not record the fact that file data has
> changed and thus fdatasync(2) has a work to do. As a result if we crash
> e.g. after a punch hole and fdatasync, user can still possibly see the
> punched out data after journal replay. Test generic/392 fails due to
> these problems.
> 
> Fix the problem by properly marking that file data has changed in these
> operations.
> 
> CC: stable@...r.kernel.org
> Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622
> Signed-off-by: Jan Kara <jack@...e.cz>

Thanks, applied.

					- Ted