linux-ext4 - Re: Potential pitfall in the clusterfs extent patches for e2fsprogs

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]

Date:	Fri, 21 Sep 2007 18:12:19 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Potential pitfall in the clusterfs extent patches for e2fsprogs

On Sep 15, 2007  21:22 -0400, Theodore Ts'o wrote:
> The problem with this is that it's fragile; you could potentially have
> an inode that happens to have as its first block something which looks
> like the extent magic number, and if the second block passes the extent
> validity checks, e2fsck will flag an error --- and if e2fsck is run in
> preen mode, it will just set the extent flag without prompting the user
> or aborting the boot process.

Well, I agree it's possible, but given that it is checking 8 bytes for
validity (though only a 2-byte magic) it seems reasonably safe.  There
are only 5 blocks in the filesystem that could correctly match in this
case (though I grant they are low-valued blocks due to little-endian
placement of the 16-bit magic).  They would have to be allocated as the
first block in the file (0x0000f30a, 0x0001f30a, ..., 0x0004f30a) and
3 always-invalid blocks that would have to be allocated as the second
block (0x000N0002, 0x000N0003, 0x000N0004).  The latter are used as
group descriptor and/or bitmap/inode table blocks, so the inode would
likely be corrupt as a non-extent inode as well.

I'm not terribly worried about it.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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