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]

Date:	Sat, 7 Jul 2007 00:50:46 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Marcel Holtmann <marcel@...tmann.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>
Subject: Re: [1/2] 2.6.22-rc7: known regressions

(CC list trimmed)

On Thu, 5 Jul 2007, Dmitry Torokhov wrote:

> > >  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
[...]
> > 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?

This should be automatically done by proper dev.parent setting of the 
corresponding input device, as already mentioned by Dmitry.

> 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...

Actually even bluetooth HID seems to set up hid->dev correctly in 
hidp_setup_hid() and also sets properly dev.parent in hidp_setup_input().

Marcel, what is please the point behind this code in 
hidp_add_connection():

        if (!session->hid) {
                session->input = input_allocate_device();
                if (!session->input) {
                        kfree(session);
                        return -ENOMEM;
                }
        }

I suspect that the oops happens during freeing this extra device which is 
not allocated inside hid core, but I can't immediately see from the code 
what is the exact purpose of this 'extra' input device and why don't the 
input devices allocated and registered in hidinput_connect() suffice? 
usbhid doesn't need to register any extra input devices, everything is 
handled solely in hid-input core.

Seems like it could be triggered by ioctl() with ca->req->rd_size set to 
0, but I am not that familiar with the bluetooth code to see it 
immediately.

Thanks,

-- 
Jiri Kosina
-
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/