linux-kernel - vfs_rmdir "bug"?

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

Message-Id: <200712232023.lBNKNST6011525@agora.fsl.cs.sunysb.edu>
Date:	Sun, 23 Dec 2007 15:23:28 -0500
From:	Erez Zadok <ezk@...sunysb.edu>
To:	hch@...radead.org, viro@....linux.org.uk
Cc:	linux-kernel@...r.kernel.org
Subject: vfs_rmdir "bug"?

Al, Christoph,

vfs_rmdir is called from do_rmdir and does essentially this:

	dentry_unhash(dentry);
	error = dir->i_op->rmdir(dir, dentry);
	if (!error)
		d_delete(dentry);
	dput(dentry);

do_rmdir grabs a ref on the dentry to be rmdir'ed, and also dput's it (so
it's nice and symmetric).  But vfs_rmdir seems asymmetric esp. when ->rmdir
returns and error (e.g., -ENOTEMPTY):

1. on error, the dentry will remain unhashed: shouldn't it be re-hashed (the
   way vfs_rename_dir does)?

2. vfs_rmdir unconditionally dput's the dentry, but it never grabbed that
   ref in the first place.  Is this really necessary.  We had a good dentry
   in the dcache before the call to rmdir(2), but after this unconditional
   dput(), it'll be removed from the dcache.  This would cause the vfs to
   have to re-issue a lookup on it next time someone tries to do anything
   with that directory.

I discovered this while trying to figure out why an expected-to-fail rmdir
on unionfs (one of the ltp tests tests for -ENOTEMPTY) left a lower inode
behind until umount(2) was called.  I fixed it by implementing
unionfs_d_iput, but still, it seems odd that we'll have dropped/unhashed a
possibly good dentry b/c ->rmdir failed.

Thanks,
Erez.
--
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/