linux-kernel - Re: [Bluez-devel] Oops involving RFCOMM and sysfs

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

Date:	Sun, 6 Jan 2008 02:18:26 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Tejun Heo <htejun@...il.com>
Cc:	Gabor Gombas <gombasg@...aki.hu>,
	Dave Young <hidave.darkstar@...il.com>,
	linux-kernel@...r.kernel.org, bluez-devel@...ts.sf.net,
	Greg KH <greg@...ah.com>, ebiederm@...ssion.com
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs

On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:

> Right, I haven't thought about that.  When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative dentry before a node is created, things can go wrong.  I don't
> think that's what's going on here tho.  If that was the case, the
> while() loop looking up the next sd to lookup (@cur) should have blown
> up as negative dentry will have NULL d_fsdata which doesn't match any sd.

No.  What happens if sd gets unlinked while we are on the way to
sysfs_get_dentry() and so does its parent?  The parent is off the
sibling list, we get negative dentry from lookup.  It's not hashed,
so won't stick around in dcache (which is apparently what you are
thinking about).  However, _THIS_ lookup has returned you a dentry
with NULL ->d_inode and you are well and truly buggered.
--
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/