linux-kernel - Re: S2R resume crash in 2.6.33-rc7 - NULL pointer dereference in dev_get

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: <Pine.LNX.4.44L0.1002081505220.1316-100000@iolanthe.rowland.org>
Date:	Mon, 8 Feb 2010 15:25:06 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
cc:	Jiri Kosina <jkosina@...e.cz>, Oliver Neukum <oliver@...kum.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Marcel Holtmann <marcel@...tmann.org>,
	H Hartley Sweeten <hsweeten@...ionengravers.com>,
	<linux-usb@...r.kernel.org>, <linux-input@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: S2R resume crash in 2.6.33-rc7 - NULL pointer dereference in
 dev_get_drvdata() for usbhid

On Mon, 8 Feb 2010, Bruno [UTF-8] PrÃ©mont wrote:

> On Mon, 08 February 2010 Bruno PrÃ©mont <bonbons@...ux-vserver.org> wrote:
> > 2.6.33-rc7 (don't know if any previous version resumes properly)
> > crashes during resume from S2Ram when my USB keyboard is connected but
> > resumes properly (viafb corruption put apart) when the USB keyboard is
> > not connected.
> 
> The patch below works around the crash though the WARN_ON() in
> usbhid_restart_out_queue() triggers in place.
> 
> Bruno
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index e2997a8..d2f8eef 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -196,7 +196,7 @@ static void usbhid_mark_busy(struct usbhid_device *usbhid)
>  
>  static int usbhid_restart_out_queue(struct usbhid_device *usbhid)
>  {
> -	struct hid_device *hid = usb_get_intfdata(usbhid->intf);
> +	struct hid_device *hid = usbhid->intf ? usb_get_intfdata(usbhid->intf) : NULL;
>  	int kicked;
>  
>  	if (!hid)
> @@ -214,7 +214,7 @@ static int usbhid_restart_out_queue(struct usbhid_device *usbhid)
>  
>  static int usbhid_restart_ctrl_queue(struct usbhid_device *usbhid)
>  {
> -	struct hid_device *hid = usb_get_intfdata(usbhid->intf);
> +	struct hid_device *hid = usbhid->intf ? usb_get_intfdata(usbhid->intf) : NULL;
>  	int kicked;
>  
>  	WARN_ON(hid == NULL);

Clearly something is setting usbhid->intf to NULL.  But I don't see any
code that would do it.  You may have to resort to putting printk()  
statements at various strategic places to find out where it happens.  
You could start with the beginnings and ends of hid_suspend,
hid_resume, and hid_reset_resume.  Maybe also usbhid_disconnect(), just
in case.

Alan Stern

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