Re: [PATCH v2] usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency

[Jia-Ju Bai]

Thanks for the reply!

I will follow the rules and revise the patch.


Best wishes,
Jia-Ju Bai

On 2023/9/25 20:08, Greg KH wrote:
> On Mon, Sep 25, 2023 at 06:07:41PM +0800, Jia-Ju Bai wrote:
> > In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
> > holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
> >
> >      spin_lock_irqsave(&hsotg->lock, flags);
> >      ...
> > 	if (!urb->hcpriv) {
> > 		dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
> > 		goto out;
> > 	}
> >      rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
> >      ...
> > out:
> >      spin_unlock_irqrestore(&hsotg->lock, flags);
> >
> > When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
> > concurrently executed, the NULL check of "urb->hcpriv" can be executed
> > before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
> > in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
> > pointer dereference.
> >
> > This possible bug is found by a static tool developed by myself.
> Because of this please follow the rules for such things as documented in
> Documentation/process/researcher-guidelines.rst
>
> > To fix this possible bug, "urb->hcpriv = NULL" should be executed with
> > holding the lock "hsotg->lock". Because I have no associated hardware,
> > I cannot test the patch in real execution, and just verify it according
> > to the code logic.
> >
> > Fixes: 33ad261aa62b ("usb: dwc2: host: spinlock urb_enqueue")
> > Signed-off-by: Jia-Ju Bai <baijiaju@xxxxxxxxxxx>
> My bot says:
>
> -----------
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - You have marked a patch with a "Fixes:" tag for a commit that is in an
>    older released kernel, yet you do not have a cc: stable line in the
>    signed-off-by area at all, which means that the patch will not be
>    applied to any older kernel releases.  To properly fix this, please
>    follow the documented rules in the
>    Documetnation/process/stable-kernel-rules.rst file for how to resolve
>    this.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot