usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency

In the Linux kernel, the following vulnerability has been resolved:

usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency

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 an experimental static analysis tool

developed by myself. This tool analyzes the locking APIs to extract

function pairs that can be concurrently executed, and then analyzes the

instructions in the paired functions to identify possible concurrency

bugs including data races and atomicity violations. The above possible

bug is reported, when my tool analyzes the source code of Linux 6.5.

To fix this possible bug, "urb->hcpriv = NULL" should be executed with

holding the lock "hsotg->lock". After using this patch, my tool never

reports the possible bug, with the kernelconfiguration allyesconfig for

x86_64. Because I have no associated hardware, I cannot test the patch

in runtime testing, and just verify it according to the code logic.