linux-ext4 - Re: [PATCH 13/54] e2fsck: on read error, don't rewrite blocks past the end of the fs

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: <20150127173507.GM2453@thunk.org>
Date:	Tue, 27 Jan 2015 12:35:07 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 13/54] e2fsck: on read error, don't rewrite blocks past
 the end of the fs

On Mon, Jan 26, 2015 at 11:36:57PM -0800, Darrick J. Wong wrote:
> If e2fsck encounters a read error on a block past the end of the
> filesystem, don't bother trying to "rewrite" the block.  We might
> still want to re-try the read to capture FS data marooned past the end
> of the filesystem, but in that case e2fsck ought to move the block
> back inside the filesystem.
> 
> This enables e2fuzz to detect writes past the end of the FS due to
> software bugs.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>

Applied, but if we have a block which is past the end of the file
system, why did we try to read it in the first place?

Was it because e2fsck was told to ignore a file system inconsistency?
Or because e2fsck didn't notice before trying to read a block?  If so,
we should look to see if there is some way we could have caught this
error in the first place.  So it might be useful to run e2fuzz and
call abort() if we try to read past the end of the file system, so we
can get a stack dump and understand what happened....

    	  	     	 	    	 - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html