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:	Tue, 21 Sep 2010 14:31:20 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Phil Turmel <philip@...mel.org>
Cc:	Mat <jackdachef@...il.com>,
	Guillaume Chazarain <guichaz@...il.com>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Oliver Neukum <oliver@...kum.org>, Alan Ott <alan@...nal11.us>,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org,
	Andreas Bombe <aeb@...ian.org>,
	Alex Riesen <raa.lkml@...il.com>,
	Gabriel C <nix.or.die@...glemail.com>
Subject: Re: [BUG, Regression, bisected] USB mouse causes bug on 1st insert,
 ignored on 2nd insert, lsusb stuck at usbdev_open

On Mon, 20 Sep 2010, Phil Turmel wrote:

> dmesg attached.  Note: the timestamp of the BUG corresponds to hal 
> startup when the external mouse is plugged in before booting.

Mat, Phil, Gabriel,

thanks for providing the dmesg with the debugging patch in place. Here we 
go:

[snip]
> [    3.268784] HID debug: usbhid_probe() -- set intfdata(ffff880137d0ac00, ffff88013a7c0000)
> [    3.278462] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input6
> [    3.285212] HID debug: hid_connect() -- hid: ffff88013a7c0000
> [    3.286141] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input7
> [    3.287413] generic-usb 0003:046D:C51B.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1/input0

hid device pointer 0xffff88013a7c0000, usb_interface pointer 
0xffff880137d0ac00. This interface doesn't get registered with hiddev.

> [    3.288338] HID debug: usbhid_probe() -- set intfdata(ffff880137d0a400, ffff880138344000)
> [    3.303524] HID debug: hid_connect() -- hid: ffff880138344000
> [    3.304424] HID debug: hiddev_connect() -- hid: ffff880138344000, hiddev: ffff880137ce9f00, intf: ffff880137d0a400
> [    3.305678] HID debug: hid_connect() -- after hiddev_connect(), hid: ffff880138344000, hiddev: ffff880137ce9f00
> [    3.306609] generic-usb 0003:046D:C51B.0002: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-1/input1

hid device pointer 0xffff880138344000, usb_interface pointer 
0xffff880137d0a400. This interface does get registered with hiddev 
(allocated at 0xffff880137ce9f00), doesn't get registered with input. So 
far so good.

[snip]
> [   22.705849] HID debug: hiddev_open(): hid: ffff88013a7c0000, hiddev: (null), intf: ffff880137d0ac00

hiddev_open() has been called. usb_find_interface(&hid_driver, minor) 
returned interface pointer 0xffff880137d0ac00. Which is bogus! Interface 
0xffff880137d0ac00 is not registered with hiddev at all, we should have 
received 0xffff880137d0a400.

We currently register minors only for those usbhid devices (through 
usb_register_dev() in hiddev_connect()) which are going to be claimed by 
hiddev. It doesn't seem to be problematic to me, and I don't undersntand 
why usb_find_interface() returns wrong interface.

I have just found out that it's actually CONFIG_USB_DYNAMIC_MINORS which 
makes the difference. When unset, the problem doesn't trigger, and 
usb_find_interface() always returns the proper interface. When 
CONFIG_USB_DYNAMIC_MINORS is being used, the oops happen.

I'll look into that.

> [   22.705859] BUG: unable to handle kernel NULL pointer dereference at (null)

This is then immediate consequence, as that device has nothing associated 
in its hiddev pointer of course.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ