linux-kernel - Re: ext3: fix ext3_dx_readdir hash collision handling

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: <20081024000109.GD7842@mit.edu>
Date:	Thu, 23 Oct 2008 20:01:09 -0400
From:	Theodore Tso <tytso@....edu>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	linux-kernel@...r.kernel.org, eugene@...ix.com, msnitzer@...ix.com,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: ext3: fix ext3_dx_readdir hash collision handling - Regression

On Thu, Oct 23, 2008 at 08:37:40AM +0200, Markus Trippelsdorf wrote:
> > I haven't been able to replicate this.  Does it matter which kernel
> > tarball you use?  And can you send me the output of "dumpe2fs -h
> > /dev/hdXX", where hdXX is the device of the filesystem where this was
> > failing?
> 
> No, it happens with _every_ tarball from a certain size on. 
> Ext4 is also affected due to d015641734cde55d2fce48a6db3983c8a029fe05 .

Sorry for not getting back to you right away; I've been in the Bay
Area the past few days, and so I haven't as much ext4 hacking time
this week.

I'm still not able to reproduce this, on a 2.6.27-git7 based kernel,
using either ext3 or ext4.  (My attempt to reproduce using ext3 shown
below; the debugfs -w commands were to replicate using a filesystem
with your hash_seed and hash algorithm as you sent in your dumpe2fs
output.  Probably not important if you say that it happens on any
kernel tarball; since I'm testing while on an airplane, I had to
generate a tar.gz file from the git repository of 2.6.27, as shown
below.)

So you're reproducing this on an unmodified kernel from Linus's tip
post 2.6.27, correct?  The funny thing is the git commit you've
identified was merged sometime just before and 2.6.27-rc5, and I
pretty sure it's in the Fedora 10 beta kernel, and so I'm a bit
surprised we haven't seen more reports of this problem than just
yours.  The question then is what is going on which means that you see
this problem rather easily, but for whatever reason it's not
reproducing easily for me.

Can you send me your .config?  Is there anything unusual about your
setup you can think of?  What distribution are you running?  You've
done an explicit revert of just that commit and it afterwards you were
unable to reproduce the problem, is that correct?

Can you reproduce it while running the "rm -rf" command under strace,
(i.e., "strace -o /tmp/strace.log rm -rf linux-2.6.27.2") and send me
the strace.log file?

Thanks, regards,

						- Ted

Script started on Thu 23 Oct 2008 07:39:57 PM EDT
Top-level shell (parent script)
Using forwarded ssh authentication socket
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
497# git archive v2.6.27 | gzip > /tmp/v2.6.27.tar.gz
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
498# mke2fs -t ext3 /dev/thunk/testext4
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
499# debugfs -w /dev/thunk/testext4
debugfs 1.41.3 (12-Oct-2008)
debugfs:  ssv s_hash_seed c3188d40-b161-4458-b3f9-22ca7788110f
debugfs:  ssv s_def_hash_version tea
debugfs:  q
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
500# mount /dev/thunk/testext4 /mnt
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
501# mkdir /mnt/v2.6.27
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
502# tar -C /mnt/v2.6.27 -x -z -f /tmp/v2.6.27.tar.gz 
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
503# /bin/rm -rf /mnt/v2.6.27
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
504# umount /mnt
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
505# uname -a
Linux closure 2.6.27-05216-g0719d38 #86 SMP Fri Oct 17 11:53:34 EDT 2008 i686 GNU/Linux
<tytso.root@...sure> {/usr/projects/linux/linux-2.6}  [master]
506# exit

Script done on Thu 23 Oct 2008 07:42:30 PM EDT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/