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:	Wed, 09 Jan 2008 18:16:02 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Gabor Gombas <gombasg@...aki.hu>
CC:	Al Viro <viro@...IV.linux.org.uk>,
	Dave Young <hidave.darkstar@...il.com>,
	linux-kernel@...r.kernel.org, bluez-devel@...ts.sf.net,
	kay.sievers@...y.org, Greg KH <greg@...ah.com>
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs

Hello,

My laptop and cell finally decided to talk to each other and I could
reproduce the bug here.  The attached patch should remove the oops.

The bug is two folded.  I just skimmed through the bluetooth code and am
very likely to wrong at places.  Please correct me where I'm wrong.

1. It's introduced by class device migration and the bug will go away
with CONFIG_SYSFS_DEPRECATED turned on.  With CONFIG_SYSFS_DEPRECATED
turned off, what used to be class devices live under actual devices.
For rfcomm, this means the rfcommN tty device now lives under the
aclXXXX node (probably represents an active connection?) instead of the
class directory.

It seems rfcommN devices are supposed to survive over disconnects so the
rfcommN device moves under the live connection while connection is alive
and retreats back to a default directory when the connection is lost.
This is all fine and dandy as long as the rfcommN device lives under
class directory as class directory never goes away.

However, with recent sysfs updates, rfcommN now lives directly under the
aclXXXX node.  If the connection goes away while rfcommN device is under
it, it gets deleted but rfcommN is still treated as alive.

This isn't supported.  sysfs doesn't allow parents to die first and the
dangling children to be salvaged using sysfs_move().

2. Which in turn exposes three bugs in sysfs
	- sysfs_lookup() returning NULL on negative lookup.  sysfs
	  code requires that all negative dentries are shot down.
	  lookup should return -ENOENT instead of NULL.
	- in move and rename, error handling is wrong.  It ends up
	  passing ERR_PTR() values to dput().
	- there was an extra dput() in sysfs_move_dir().

The attached patch fixes all sysfs bugs and removes the oops.  However,
rfcommX moving is still broken.  The rfcommX device won't be visible
from sysfs tree after the initial move failure and all following moves
will fail.

Please confirm the attached patch fixes the oops.  I'll separate it into
two patches and forward them to Greg.  But bluetooth code also needs to
be updated such that it moves the refcommX device before killing the
connection node.

Thanks.

-- 
tejun

View attachment "sysfs-fixes.patch" of type "text/x-patch" (1562 bytes)