CVE-2023-52855

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.