linux-ext4 - 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-next>] [day] [month] [year] [list]

Date:	Sat, 15 Sep 2007 21:22:40 -0400
From:	"Theodore Ts'o" <tytso@....edu>
To:	linux-ext4@...r.kernel.org
Subject: Potential pitfall in the clusterfs extent patches for e2fsprogs

I've been busy working on extents support in e2fsck, and so as part of
that I was looking at the clusterfs extent patches (mostly for
inspiration to see how they work).  One of the things which I noticed is
the patches seem to check the inode direct blocks, and if they look like
the extent header, but the EXTENTS_FL flag isn't set, it flags this as
an error.  

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.

Not a problem for people who are using it for testing, but if anyone is
using these patches in production (such as Gentoo, cough, who is
shipping the patches), I thought I should give a warning --- these
patches are not ready for prime-time, and anyone who wants to use it
production will probably want to take out that particular check.

						- 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