linux-kernel - Re: 2.6.26rc9+git bluetooth/rfcomm oops

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: <19f34abd0807130925g3001109cm6bdee9baad701960@mail.gmail.com>
Date:	Sun, 13 Jul 2008 18:25:54 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Soeren Sonnenburg" <kernel@....de>
Cc:	"Dave Young" <hidave.darkstar@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org
Subject: Re: 2.6.26rc9+git bluetooth/rfcomm oops

On Sun, Jul 13, 2008 at 12:32 PM, Soeren Sonnenburg <kernel@....de> wrote:
> Hi,
>
> this oops happened after a couple of s2ram cycles so it might be very
> well crap. However I somehow triggered it by /etc/init.d/bluetooth
> stop/start's which also call hid2hci maybe even a connection was about
> to be established at that time. As I remember having seen a problem like
> this before I thought I report it (even though I have a madwifi tainted
> kernel).
>
> [drm] Num pipes: 1
> kobject_add_internal failed for rfcomm0 with -EEXIST, don't try to register things with the same name in the same directory.

Hi,

Thanks for the report.

I was able to reproduce your Oops:

kobject_add_internal failed for rfcomm0 with -EEXIST, don't try to
register things with the same name in the same directory.
Pid: 2534, comm: a.out Not tainted 2.6.26-rc9-00132-g9df2fe9 #24
 [<c0210161>] kobject_add_internal+0x108/0x13e
 [<c0210478>] kobject_add+0x4a/0x4e
 [<c026e258>] device_add+0x62/0x446
 [<c020feb9>] kobject_init+0x32/0x53
 [<c026e6c4>] device_create_vargs+0x78/0x99
 [<c026e707>] device_create+0x22/0x26
 [<c02521be>] tty_register_device+0x97/0xa2
 [<c0110000>] __cpu_disable+0x10b/0x130
 [<c03721c8>] sk_prot_alloc+0x1c/0x61
 [<c03ea86e>] rfcomm_dev_ioctl+0x213/0x582
 [<c03e9342>] rfcomm_sock_ioctl+0x1e/0x2d
 [<c03715c5>] sock_ioctl+0x152/0x175
 [<c0371473>] sock_ioctl+0x0/0x175
 [<c0166538>] vfs_ioctl+0x1c/0x5d
 [<c01667b6>] do_vfs_ioctl+0x23d/0x254
 [<c037119d>] sys_socketcall+0x51/0x181
 [<c01667f9>] sys_ioctl+0x2c/0x43
 [<c0103569>] sysenter_past_esp+0x6a/0x91
 =======================

This is because the device may be unregistered even though a reference
to it is held. When we try to register it again, the kobject layer
burps because the tty parts have not been unregistered yet. (This only
happens when the device is finally destroyed, i.e. no references.)

I don't know how to fix this, but I've attached a reproducer and added
a couple of Ccs.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

View attachment "rfcomm.c" of type "text/x-csrc" (2182 bytes)