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: <20180628221219.GC8521@thunk.org>
Date:   Thu, 28 Jun 2018 18:12:19 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsck: do not allow initialized blocks pass i_size

On Thu, Jun 28, 2018 at 01:55:49PM -0600, Andreas Dilger wrote:
> On Jun 28, 2018, at 7:59 AM, Lukas Czerner <lczerner@...hat.com> wrote:
> > 
> > We do not allow initialized blocks to exist past i_size as this could
> > lead to stale data exposure.
> 
> I don't think this is any more dangerous than uninitialized bytes beyond
> i_size in the same block, or as a hole in the middle of the file exposing
> stale data.  That is to say, there is some risk, but not any worse.  The
> converse is true also - extendiy,ng i_size to the end of the allocated blocks
> will not only expose that data, but in some cases make applications think
> the file is corrupted because there are now NULs at the end of the file.

I believe what Lukas is referring to is the fact that historically,
ext2, ext3, and ext4 in the nodelalloc case used i_size as the
interlock to make sure we don't end up exposing stale data.  With the
advent of punch hole functionality, life gets interesting so we have
one set of mechanisms for interlocking between buffered and direct I/O
for truncate, and different one for punch hole.

So the kernel should never create intialized blocks past i_size.  I've
done some quick checks, and this appears to be correct.

     	  		    	 	    - Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ