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

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]

Message-ID: <d120d5000707051403r1d946375nb119ff86b26580ef@mail.gmail.com>
Date:	Thu, 5 Jul 2007 17:03:48 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"David Woodhouse" <dwmw2@...radead.org>,
	"Jiri Kosina" <jkosina@...e.cz>,
	"Michal Piotrowski" <michal.k.k.piotrowski@...il.com>,
	marcel@...tmann.org, "Andrew Morton" <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	reiserfs-devel@...r.kernel.org,
	"Vladimir V. Saveliev" <vs@...esys.com>,
	"Randy Dunlap" <randy.dunlap@...cle.com>,
	linux-ide@...r.kernel.org, "David Chinner" <dgc@....com>,
	sparclinux@...r.kernel.org, "David Miller" <davem@...emloft.net>,
	"Mikael Pettersson" <mikpe@...uu.se>,
	"Mark Fortescue" <mark@...hpc.demon.co.uk>,
	"William Lee Irwin III" <wli@...omorphy.com>,
	"Greg KH" <greg@...ah.com>
Subject: Re: [1/2] 2.6.22-rc7: known regressions

On 7/5/07, Linus Torvalds <torvalds@...ux-foundation.org> 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-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/