| 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
| ||
|
Date: Thu, 13 Mar 2008 16:17:48 -0400 From: Theodore Tso <tytso@....edu> To: Andreas Dilger <adilger@....com> Cc: linux-ext4@...r.kernel.org Subject: Re: The e2fsprogs nlinks-dir patch On Thu, Mar 13, 2008 at 12:01:27PM -0700, Andreas Dilger wrote: > > So if it is the actual and on-disk count is different, but the inode in > > question is an inode and the on-disk count is 1, but the actual count is > ^^^^^ directory? Yes, directory. Sorry for the typo.... > > The number 65538 will get masked down to 2. Hilarity then ensues. > > Can you expand? I tested the kernel and a link count of 2 will still > result in the "ext3_is_empty()" function being called prior to doing > the unlink and it will be refused. If a subdirectory is removed at > that point nlink will go down to 1 again and all is well? Hmm, you're right. It's still results in an incorrect value, but it shouldn't totally blow us out of the water if we attempt an rmdir. The one problem I can think of is that find and some other directory iterators had some optimizations which depended on st_nlink being correct. They've been patched so that the optimizatoins are turned off if st_nlink is 1 for directories. But if st_nlink is both incorrect and > 1, it could cause them to terminate their search too soon. - 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
Powered by blists - more mailing lists