Received-SPF: pass (google.com: domain of linux-kernel+bounces-16693-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 4 Jan 2024 14:13:51 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Udipto Goswami <quic_ugoswami@quicinc.com>
Cc: Alan Stern <stern@rowland.harvard.edu>, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: core: Prevent null pointer dereference in
 update_port_device_state
Message-ID: <2024010432-fifth-shakable-0d84@gregkh>
References: <20240104102616.20120-1-quic_ugoswami@quicinc.com>
 <2024010447-sprite-shelter-0743@gregkh>
 <eade09eb-4454-460f-9ce6-87da986c5acf@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <eade09eb-4454-460f-9ce6-87da986c5acf@quicinc.com>

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