Re: [1/2] 2.6.22-rc7: known regressions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/5/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

Looks input-related..

On Thu, 5 Jul 2007, David Woodhouse wrote:
>
> Hm, it's not something new. It's an oops I saw occasionally in 2.6.21-rc
> too, whenever we had CONFIG_SYSFS_DEPRECATED set.
>
>  Unable to handle kernel paging request for data at address 0x6b6b6b6b

Ok, that 0x6b is obviously the kfree() poisoning, ie it looks like a
use-after-free problem with a pointer being loaded from a structure that
had been free'd-

And the trace seems to be (ignore the unreliable one):

>  NIP [c001870c] strlen+0x4/0x18
>  LR [c0134fec] kobject_get_path+0x34/0xc4
>  Call Trace:
>  [eed5be90] [c01d5124] class_uevent+0xac/0x1bc
>  [eed5bed0] [c01357e4] kobject_uevent_env+0x23c/0x460
>  [eed5bf20] [c01d485c] class_device_del+0x178/0x1a0
>  [eed5bf40] [c01d489c] class_device_unregister+0x18/0x30
>  [eed5bf60] [c021f820] input_unregister_device+0xf4/0x130
>  [eed5bf70] [c0242f4c] hidinput_disconnect+0x2c/0x60
>  [eed5bf90] [f27f2bac] hidp_session+0x550/0x584 [hidp]
>  [eed5bff0] [c0013e28] kernel_thread+0x44/0x60

Where we have a few missing functions due to inlining, ie the real
sequence seems to be:

class_device_del ->
 kobject_uevent_env ->
   class_uevent ->
     kobject_get_path ->
       get_kobj_path_length ->
         parent = kobj;
         do {
           strlen(parent->k_name /* kobject_name(parent) */);
           parent = parent->parent;
         } while (parent);

so either the kobj or one of it's parents had already been freed when it
was unregistered due to the disconnect.

I'm not seeing any reference counting or other protection for the device
("input") on "hid->inputs" list. But I don't know the code. Dmitry? Jiri?


In hidinput_connect we do:

         input_dev->dev.parent = hid->dev;

This should pin hid object untill all inputs are released. However
bluetooth does not use driver model and does not have hid->dev set up
and so it looks like we are simply trying to unregister an input
device that is already gone... I still don't quite get how we
unregister the same device twice - it is done from a per-hid-device
thread in hidp...

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux