Hi, Plugging in a 0471:206c 'Spinel plusf0r Asus' IR receiver with the more recent mceusb module versions Oops'es the kernel with a null pointer deref. I'm currently seeing this in 3.12.0 (Ubuntu stock) but i recall seeing this problem since about 3.8+ kernels. I kinda hoped it'd go away over time but it's still there so i've dug deeper... For this Oops the IR receiver was plugged in after the system finished booting and a session was started for the user. After the Oops it was impossible to unload the module, rmmod and usb [for that device] would hang, replugging produced no further output, udev borked, reboot needed. Full dmesg output: https://8n1.org/9514/9621 Excerpt: | BUG: unable to handle kernel NULL pointer dereference at 0000000000000002 | IP: [<ffffffffa06fef0c>] mce_request_packet+0x14c/0x240 [mceusb] | Oops: 0000 [#1] SMP | CPU: 1 PID: 1447 Comm: systemd-udevd Not tainted 3.12.0-7-generic #15-Ubuntu | [ .. ] | Call Trace: | [<ffffffffa06ff05a>] mce_async_out+0x5a/0x70 [mceusb] | [<ffffffffa06ff9cd>] mceusb_dev_probe+0x61d/0xcb0 [mceusb] | [<ffffffff8136e43f>] ? idr_get_empty_slot+0x16f/0x3c0 | [<ffffffff81190053>] ? SyS_get_mempolicy+0x63/0x480 | [<ffffffff815458e4>] usb_probe_interface+0x1c4/0x2f0 | [ .. ] In this (https://8n1.org/9516/836d) source file from 3.12.0 the Oops is triggered first time mce_request_packet() is run with urb_type == MCEUSB_TX in mceusb_dev_probe() and ir->usb_ep_out is accessed. The actual problem is that the mceusb_dev_probe function and everything later on just assumes ep_out is set while ep_in is explicitly checked for null value in that same routine at line 1298. I'm no kernel hacker nor am i a USB expert so i'm not sure wether or not ep_out is mandatory but looking at the rest of the code it would seem the function should return -ENODEV as with ep_in == NULL. That's a bug, no? And why would there (suddenly) not be any 'out' endpoints? It still worked with 2.6 kernels and a hack[*]. According to mceusb.c, mceusb.c changed a fair bit or was introduced since about Linux 3.6/3.8 which matches the fuzzy moment i remember this being broken. :) The full lsusb output for this device is at https://8n1.org/9517/2163, Excerpt: | Device: ID 0471:206c Philips (or NXP) MCE IR Receiver - Spinel plusf0r ASUS | Interface Descriptor: | bInterfaceClass 3 Human Interface Device | bInterfaceSubClass 1 Boot Interface Subclass | bInterfaceProtocol 1 Keyboard | HID Device Descriptor: | bDescriptorType 33 | bNumDescriptors 1 | bDescriptorType 34 Report | Report Descriptors: | ** UNAVAILABLE ** | Endpoint Descriptor: | bDescriptorType 5 | bEndpointAddress 0x81 EP 1 IN The '** UNAVAILABLE **'-bit seems alarming to me. Googling around indicates it's a common thing, though often it's in reports aparently about the same null pointer dereference. Which seems strange to me, but there's only a few threads in 2012 and i cant find much more than 'it does not work, help' with no real insightful answers. [*]With the older 2.6 kernels i had a special 'driver' kernel module called hid-philips-asus.c (https://8n1.org/9519/bbf4) which seems fairly simple. Back then it was important to load it before usbhid.ko was loaded so it could claim the IR receiver before the kernels USBHID implementation would. There was no support from stock kernel, iirc. With 3.12.0 i dont see reason to assume this hackery is still necessary. Could someone nudge me in the right direction? Thanks! -Sander. (HppyNwYr!) -- | At times i use words i don't fully understand to apear more coagulated. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
Attachment:
signature.asc
Description: Digital signature
