linux-kernel - Re: 2.6.26-rc7-mmotd-0626 ext3-validate-directory-entry-data-before-use.patch

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: <Pine.LNX.4.64.0806291218390.30797@blonde.site>
Date:	Sun, 29 Jun 2008 12:31:23 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Valdis.Kletnieks@...edu
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Duane Griffin <duaneg@...da.com>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.26-rc7-mmotd-0626 ext3-validate-directory-entry-data-before-use.patch

On Sun, 29 Jun 2008, Valdis.Kletnieks@...edu wrote:
> I'm seeing some ext3 errors, and I'm suspecting the patch
> ext3-validate-directory-entry-data-before-use.patch is causing them
> (since it seems to be the only thing in rc7-mmotd at the moment that
> touches make_indexed_dir, and -rc5-mm3 works OK).
> 
> Jun 28 21:50:29 turing-police kernel: [  240.784199] EXT3-fs error (device dm-7): make_indexed_dir: bad entry in directory #9894: directory entry across blocks - offset=0, inode=10144, rec_len=32, name_len=22
> Jun 28 21:50:29 turing-police kernel: [  240.784214] Aborting journal on device dm-7.
> Jun 28 21:50:29 turing-police kernel: [  240.784597] Remounting filesystem read-only
> Jun 28 21:50:29 turing-police kernel: [  240.785616] EXT3-fs error (device dm-7): do_split: bad entry in directory #9894: rec_len is smaller than minimal - offset=0, inode=2553887680, rec_len=0, name_len=0
> Jun 28 21:50:29 turing-police kernel: [  240.785616] EXT3-fs error (device dm-7) in ext3_reserve_inode_write: Journal has aborted
> Jun 28 21:50:29 turing-police kernel: [  241.027111] __journal_remove_journal_head: freeing b_committed_data
> 
> Jun 28 23:09:54 turing-police kernel: [ 5026.698415] EXT3-fs error (device dm-2): make_indexed_dir: bad entry in directory #369136: directory entry across blocks - offset=0, inode=369138, rec_len=20, name_len=11
> Jun 28 23:09:54 turing-police kernel: [ 5026.698415] Aborting journal on device dm-2.
> Jun 28 23:09:54 turing-police kernel: [ 5026.698519] Remounting filesystem read-only
> Jun 28 23:09:54 turing-police kernel: [ 5026.702730] EXT3-fs error (device dm-2): do_split: bad entry in directory #369136: directory entry across blocks - offset=0, inode=106647, rec_len=12, name_len=1
> Jun 28 23:09:54 turing-police kernel: [ 5026.702730] EXT3-fs error (device dm-2) in ext3_reserve_inode_write: Journal has aborted
> 
> I believe I have a reasonably good replicator for the error on dm-7, that's my /usr/share
> and trying to 'rpm -Fvh' one specific RPM has caused it twice (in two tries).
> 
> The file systems appear to be OK (or at least the fsck.ext3 in Fedora's
> e2fsprogs-1.41-0.WIP.0617.1.fc10.x86_64 says both file systems are in fact OK).
> 
> Any comments/suggestions?  Any testing/debugging you'd like,
> or should I just revert it and move on?

Thanks for the warning, yes, me too.  All I have to do is boot up and
cp -al a kernel source tree: that starts generating lots of these errors,
I Ctrl-C out, unmount the filesystem, then fsck -f has lots of work to do.

So not only does the patch find directory entries invalid which have
given no trouble in the past, it handles them in such a way as to
leave the filesystem messed up where it wasn't before.

And build even gives a compile warning, haven't looked if it's significant:
fs/ext3/namei.c: In function ‘make_indexed_dir’:
fs/ext3/namei.c:1435: warning: comparison of distinct pointer types lacks a cast

I think I don't want to investigate this one!  I've hurriedly reverted

ext3-validate-directory-entry-data-before-use-checkpatch-fixes.patch
ext3-validate-directory-entry-data-before-use.patch

, checked that cp -al on the kernel source tree now gives me no errors,
checked that fsck -f is happy with the resultant filesystem,
now moving on.

Hugh