2.6.20-rc4: null pointer deref in khubd

2.6.20-rc4: null pointer deref in khubd

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4401 bytes --]

Hi!

I have half broken usb device here, very useful at breaking linux usb
stack:

(Is it softlockup watchdog triggering in the middle of oops? Do we
take too long to oops or what?)
								Pavel
...
PM: Adding info for usb:2-1:1.0
usb0: register 'cdc_ether' at usb-0000:00:1d.0-1, CDC Ethernet Device, c2:3a:65:0e:e0:f7
PM: Adding info for No Bus:usbdev2.60_ep83
PM: Adding info for usb:2-1:1.1
PM: Adding info for No Bus:usbdev2.60_ep81
PM: Adding info for No Bus:usbdev2.60_ep02
PM: Adding info for mmc:mmc0:0001
mmcblk0: mmc0:0001 IFX128 125440KiB 
 mmcblk0: p1 p2 p3
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
usb 2-1: USB disconnect, address 60
PM: Removing info for No Bus:usbdev2.60_ep83
usb0: unregister 'cdc_ether' usb-0000:00:1d.0-1, CDC Ethernet Device
PM: Removing info for usb:2-1:1.0
PM: Removing info for No Bus:usbdev2.60_ep81
PM: Removing info for No Bus:usbdev2.60_ep02
PM: Removing info for usb:2-1:1.1
PM: Removing info for No Bus:usbdev2.60_ep00
PM: Removing info for usb:2-1
usb 2-1: new full speed USB device using uhci_hcd and address 61
usb 2-1: device descriptor read/64, error -71
PM: Removing info for mmc:mmc0:0001
usb 2-1: new full speed USB device using uhci_hcd and address 62
usb 2-1: device descriptor read/64, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 63
usb 2-1: new full speed USB device using uhci_hcd and address 64
usb 2-1: new full speed USB device using uhci_hcd and address 65
usb 2-1: new full speed USB device using uhci_hcd and address 66
usb 2-1: device descriptor read/all, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 68
usb 2-1: USB disconnect, address 68
usb 2-1: unable to read config index 0 descriptor/start
usb 2-1: chopping to 0 config(s)
usb 2-1: string descriptor 0 read error: -19
usb 2-1: string descriptor 0 read error: -19
PM: Adding info for usb:2-1
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000010
 printing eip:
c0610784
*pde = 00000000
PM: Adding info for No Bus:usbdev2.68_ep00
usb 2-1: no configuration chosen from 0 choices
BUG: soft lockup detected on CPU#1!
 [<c014d4c9>] softlockup_tick+0xa9/0xd0
 [<c0131393>] update_process_times+0x33/0x80
 [<c011ab7b>] smp_apic_timer_interrupt+0x6b/0x80
 [<c0103aa4>] apic_timer_interrupt+0x28/0x30
 [<c02558b4>] delay_tsc+0x14/0x20
 [<c02558f6>] __delay+0x6/0x10
 [<c011fbbb>] do_page_fault+0x35b/0x600
 [<c011f860>] do_page_fault+0x0/0x600
 [<c061352c>] error_code+0x7c/0x84
 [<c0610784>] klist_del+0x14/0x50
 [<c0328edb>] device_del+0x1b/0x1c0
 [<c044c2a1>] usb_disconnect+0xb1/0x120
 [<c044ec4a>] hub_thread+0x3ca/0xe00
 [<c0120ab1>] __activate_task+0x21/0x40
 [<c01238af>] try_to_wake_up+0x3f/0x420
 [<c013c6c0>] autoremove_wake_function+0x0/0x50
 [<c044e880>] hub_thread+0x0/0xe00
 [<c013c60c>] kthread+0xec/0xf0
 [<c013c520>] kthread+0x0/0xf0
 [<c0103be7>] kernel_thread_helper+0x7/0x10
 =======================
Oops: 0000 [#1]
SMP 
Modules linked in: usbserial
CPU:    1
EIP:    0060:[<c0610784>]    Not tainted VLI
EFLAGS: 00010292   (2.6.20-rc4 #387)
EIP is at klist_del+0x14/0x50
eax: 00000000   ebx: 00000000   ecx: 0000000f   edx: 00000000
esi: 0000007c   edi: df17c4f4   ebp: df17c5c8   esp: c21b3ea4
ds: 007b   es: 007b   ss: 0068
Process khubd (pid: 304, ti=c21b2000 task=c2264030 task.ti=c21b2000)
Stack: df17c504 0000007c df17c4e0 c0328edb f79f76d0 df17c504 0000007c df17c488 
       df17c5c8 c044c2a1 c0735194 c0704518 df17c598 00000044 f79f78f8 df17c4e0 
       c21ffd1c c2251b50 f79f7678 c21ffd04 c044ec4a c21b3fb0 0000000a c21b3f10 
Call Trace:
 [<c0328edb>] device_del+0x1b/0x1c0
 [<c044c2a1>] usb_disconnect+0xb1/0x120
 [<c044ec4a>] hub_thread+0x3ca/0xe00
 [<c0120ab1>] __activate_task+0x21/0x40
 [<c01238af>] try_to_wake_up+0x3f/0x420
 [<c013c6c0>] autoremove_wake_function+0x0/0x50
 [<c044e880>] hub_thread+0x0/0xe00
 [<c013c60c>] kthread+0xec/0xf0
 [<c013c520>] kthread+0x0/0xf0
 [<c0103be7>] kernel_thread_helper+0x7/0x10
 =======================
Code: 04 89 46 04 89 4a 04 89 11 c6 03 01 8b 1c 24 8b 74 24 04 83 c4 08 c3 83 ec 0c 89 7c 24 08 89 c7 89 1c 24 89 74 24 04 8b 18 89 d8 <8b> 73 10 e8 f4 29 00 00 89 f8 e8 ad fe ff ff 85 c0 b8 00 00 00 
EIP: [<c0610784>] klist_del+0x14/0x50 SS:ESP 0068:c21b3ea4
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: delme.bz2 --]
[-- Type: application/octet-stream, Size: 18485 bytes --]

Re: 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> usb 2-1: new full speed USB device using uhci_hcd and address 68
> usb 2-1: USB disconnect, address 68
> usb 2-1: unable to read config index 0 descriptor/start
> usb 2-1: chopping to 0 config(s)

Does anybody know a legitimate reasons a device should have
0 configurations? Independent of the reason of this bug, should we disallow
such devices and error out?

	Regards
		Oliver

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Alan Stern]

On Wed, 10 Jan 2007, Oliver Neukum wrote:

> Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > usb 2-1: USB disconnect, address 68
> > usb 2-1: unable to read config index 0 descriptor/start
> > usb 2-1: chopping to 0 config(s)
> 
> Does anybody know a legitimate reasons a device should have
> 0 configurations? Independent of the reason of this bug, should we disallow
> such devices and error out?

About the only reason to allow such devices is so that the user can run 
lsusb to try and get more information about the problem.  With no 
configurations, the device won't be useful for anything.

Alan Stern

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Mittwoch, 10. Januar 2007 17:14 schrieb Alan Stern:
> On Wed, 10 Jan 2007, Oliver Neukum wrote:
> 
> > Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > > usb 2-1: USB disconnect, address 68
> > > usb 2-1: unable to read config index 0 descriptor/start
> > > usb 2-1: chopping to 0 config(s)
> > 
> > Does anybody know a legitimate reasons a device should have
> > 0 configurations? Independent of the reason of this bug, should we disallow
> > such devices and error out?
> 
> About the only reason to allow such devices is so that the user can run 
> lsusb to try and get more information about the problem.  With no 
> configurations, the device won't be useful for anything.

Regarding the bug this device uncovers, it seems to me that this in drivers/base/core.c
	if (parent)
		klist_add_tail(&dev->knode_parent, &parent->klist_children);
should make knode_parent a valid node under all circumstances.
Hm.

	Regards
		Oliver

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Alan Stern]

On Wed, 10 Jan 2007, Oliver Neukum wrote:

> Am Mittwoch, 10. Januar 2007 17:14 schrieb Alan Stern:
> > On Wed, 10 Jan 2007, Oliver Neukum wrote:
> > 
> > > Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > > > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > > > usb 2-1: USB disconnect, address 68
> > > > usb 2-1: unable to read config index 0 descriptor/start
> > > > usb 2-1: chopping to 0 config(s)
> > > 
> > > Does anybody know a legitimate reasons a device should have
> > > 0 configurations? Independent of the reason of this bug, should we disallow
> > > such devices and error out?
> > 
> > About the only reason to allow such devices is so that the user can run 
> > lsusb to try and get more information about the problem.  With no 
> > configurations, the device won't be useful for anything.
> 
> Regarding the bug this device uncovers, it seems to me that this in drivers/base/core.c
> 	if (parent)
> 		klist_add_tail(&dev->knode_parent, &parent->klist_children);
> should make knode_parent a valid node under all circumstances.
> Hm.

I haven't seen the original bug report.  Where does the NULL pointer deref 
occur?

Alan Stern

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Mittwoch, 10. Januar 2007 18:31 schrieb Alan Stern:
> > Regarding the bug this device uncovers, it seems to me that this in drivers/base/core.c
> >       if (parent)
> >               klist_add_tail(&dev->knode_parent, &parent->klist_children);
> > should make knode_parent a valid node under all circumstances.
> > Hm.
> 
> I haven't seen the original bug report.  Where does the NULL pointer deref 
> occur?

Apparently here: drivers/base/core.c:

void device_del(struct device * dev)
{
	struct device * parent = dev->parent;
	struct class_interface *class_intf;

	if (parent)
		klist_del(&dev->knode_parent);

The obvious change with this device is that usb_set_configuration() is never
called, but that should not matter.

	Regards
		Oliver

Re: 2.6.20-rc4: null pointer deref in khubd

[Pavel Machek]

Hi!

> > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > usb 2-1: USB disconnect, address 68
> > usb 2-1: unable to read config index 0 descriptor/start
> > usb 2-1: chopping to 0 config(s)
> 
> Does anybody know a legitimate reasons a device should have
> 0 configurations? Independent of the reason of this bug, should we disallow
> such devices and error out?

It is not bad device, btw, but extremely flakey connector. Bug is
random :-(, and machine is smp, so it might even be a race.

						Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Alan Stern]

On Wed, 10 Jan 2007, Oliver Neukum wrote:

> Am Mittwoch, 10. Januar 2007 18:31 schrieb Alan Stern:
> > > Regarding the bug this device uncovers, it seems to me that this in drivers/base/core.c
> > >       if (parent)
> > >               klist_add_tail(&dev->knode_parent, &parent->klist_children);
> > > should make knode_parent a valid node under all circumstances.
> > > Hm.
> > 
> > I haven't seen the original bug report.  Where does the NULL pointer deref 
> > occur?
> 
> Apparently here: drivers/base/core.c:
> 
> void device_del(struct device * dev)
> {
> 	struct device * parent = dev->parent;
> 	struct class_interface *class_intf;
> 
> 	if (parent)
> 		klist_del(&dev->knode_parent);
> 
> The obvious change with this device is that usb_set_configuration() is never
> called, but that should not matter.

No, I think you're barking up the wrong tree.

Pavel, did you have CONFIG_USB_MULTITHREAD_PROBE turned on?  I bet you did 
-- there's no other way to generate the messages in your syslog.

Don't use that kconfig option.  It's broken (as you saw) and needs to be
either removed or replaced.

Alan Stern

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Pavel Machek]

Hi!

> > The obvious change with this device is that usb_set_configuration() is never
> > called, but that should not matter.
> 
> No, I think you're barking up the wrong tree.
> 
> Pavel, did you have CONFIG_USB_MULTITHREAD_PROBE turned on?  I bet you did 
> -- there's no other way to generate the messages in your syslog.

Yep, you are right.

> Don't use that kconfig option.  It's broken (as you saw) and needs to be
> either removed or replaced.

Perhaps it should be disabled before 2.6.20? This is actually
regression...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Mittwoch, 10. Januar 2007 23:35 schrieb Alan Stern:
> > Apparently here: drivers/base/core.c:
> > 
> > void device_del(struct device * dev)
> > {
> >       struct device * parent = dev->parent;
> >       struct class_interface *class_intf;
> > 
> >       if (parent)
> >               klist_del(&dev->knode_parent);
> > 
> > The obvious change with this device is that usb_set_configuration() is never
> > called, but that should not matter.
> 
> No, I think you're barking up the wrong tree.

OK. Next time I'll ask about config options before going through working
code looking for a bug.

	Regards
		Oliver

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Pavel Machek]

On Thu 2007-01-11 08:48:53, Oliver Neukum wrote:
> Am Mittwoch, 10. Januar 2007 23:35 schrieb Alan Stern:
> > > Apparently here: drivers/base/core.c:
> > > 
> > > void device_del(struct device * dev)
> > > {
> > >       struct device * parent = dev->parent;
> > >       struct class_interface *class_intf;
> > > 
> > >       if (parent)
> > >               klist_del(&dev->knode_parent);
> > > 
> > > The obvious change with this device is that usb_set_configuration() is never
> > > called, but that should not matter.
> > 
> > No, I think you're barking up the wrong tree.
> 
> OK. Next time I'll ask about config options before going through working
> code looking for a bug.

Can we delete that config option for 2.6.20? (And sorry for a crappy report).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Donnerstag, 11. Januar 2007 11:34 schrieb Pavel Machek:

[on USB_MULTITHREAD_PROBE]
> Can we delete that config option for 2.6.20? (And sorry for a crappy report).

Somebody already has done so, however he left the module parameter.
I'll remove that, too.

	Regards
		Oliver

Re: [linux-usb-devel] 2.6.20-rc4: null pointer deref in khubd

[Oliver Neukum]

Am Mittwoch, 10. Januar 2007 21:38 schrieb Pavel Machek:
> Hi!
> 
> > > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > > usb 2-1: USB disconnect, address 68
> > > usb 2-1: unable to read config index 0 descriptor/start
> > > usb 2-1: chopping to 0 config(s)
> > 
> > Does anybody know a legitimate reasons a device should have
> > 0 configurations? Independent of the reason of this bug, should we disallow
> > such devices and error out?
> 
> It is not bad device, btw, but extremely flakey connector. Bug is
> random :-(, and machine is smp, so it might even be a race.

With that config option, there's a race even on UP. probe() can
sleep.

	Regards
		Oliver