linux-kernel - Re: [PATCH] usb: core: Prevent null pointer dereference in update_port_device

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: <2024010432-fifth-shakable-0d84@gregkh>
Date: Thu, 4 Jan 2024 14:13:51 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Udipto Goswami <quic_ugoswami@...cinc.com>
Cc: Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: core: Prevent null pointer dereference in
 update_port_device_state

On Thu, Jan 04, 2024 at 06:35:38PM +0530, Udipto Goswami wrote:
> Hi Greg,
> 
> On 1/4/2024 4:14 PM, Greg Kroah-Hartman wrote:
> > On Thu, Jan 04, 2024 at 03:56:16PM +0530, Udipto Goswami wrote:
> > > Currently,the function update_port_device_state gets the usb_hub from
> > > udev->parent by calling usb_hub_to_struct_hub.
> > > However, in case the actconfig or the maxchild is 0, the usb_hub would
> > > be NULL and upon further accessing to get port_dev would result in null
> > > pointer dereference.
> > 
> > Is this true for any real (or fake) hardware?
> 
> We saw this in our QCOM hardwares where lvstest.c was calling
> get_dev_desc_store:
> 
> 	usb_set_device_state+0x128/0x17c
> 	create_lvs_device+0x60/0xf8 [lvstest]
> 	get_dev_desc_store+0x94/0x18c [lvstest]
> 	dev_attr_store+0x30/0x48
> 
> I think the part of the test procedure is to first unbind the hub driver
> which calls hub_disconnect setting the maxchild = 0.

Are you sure lvstest is correct here?

thanks,

greg k-h