linux-ext4 - Re: e2fsck aborts when invalid indirect block is encountered

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: <20110901170039.GA4110@thunk.org>
Date:	Thu, 1 Sep 2011 13:00:39 -0400
From:	Ted Ts'o <tytso@....edu>
To:	linux-ext4@...r.kernel.org
Subject: Re: e2fsck aborts when invalid indirect block is encountered

On Thu, Sep 01, 2011 at 02:34:10PM +0800, Chen Huan wrote:
> Hi, All.
> 
> During a recent read-only checking of an corrupted ext3 file system,
> I found a strange behaviour of e2fsck: when an inode has an invalid
> indirect block number, e2fsck aborts with the following message:
> 
>     e2fsck 1.39 (29-May-2006)
>     Pass 1: Checking inodes, blocks, and sizes
>     Inode 12 has illegal block(s).  Clear? no
> 
>     Illegal block #-1 (4294967295) in inode 12.  IGNORED.
>     Error while iterating over blocks in inode 12: Illegal indirect block found
>     e2fsck: aborted

> My question is: Is this behaviour a bug or intended?

This is deliberate.  There are two reasons for this:

(1) e2fsck -n is currently defined as being equivalent to (a) opening
the file system read-only, and (b) answering 'no' to all questions
asked by e2fsck.

(2) In the case where you *aren't* doing an e2fsck -n, there are
certain situations where not correcting an error means (a) that its
dangerous to try to fix anything afterwards, and that (b) many of the
diagnostics issued by e2fsck can not be relied upon.

We could change things so that e2fsck doesn't abort in the case where
-n is specified, which would avoid the problem 2a, but it breaks the
definition of 1b.  It also doesn't solve the problem listed in 2b.
Still, if it's really annoying it's something I could consider
changing.  Let me sleep on it.

	      	      	   	   - 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