CVE-2023-52855

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency<br /> <br /> In _dwc2_hcd_urb_enqueue(), "urb-&gt;hcpriv = NULL" is executed without<br /> holding the lock "hsotg-&gt;lock". In _dwc2_hcd_urb_dequeue():<br /> <br /> spin_lock_irqsave(&amp;hsotg-&gt;lock, flags);<br /> ...<br /> if (!urb-&gt;hcpriv) {<br /> dev_dbg(hsotg-&gt;dev, "## urb-&gt;hcpriv is NULL ##\n");<br /> goto out;<br /> }<br /> rc = dwc2_hcd_urb_dequeue(hsotg, urb-&gt;hcpriv); // Use urb-&gt;hcpriv<br /> ...<br /> out:<br /> spin_unlock_irqrestore(&amp;hsotg-&gt;lock, flags);<br /> <br /> When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are<br /> concurrently executed, the NULL check of "urb-&gt;hcpriv" can be executed<br /> before "urb-&gt;hcpriv = NULL". After urb-&gt;hcpriv is NULL, it can be used<br /> in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL<br /> pointer dereference.<br /> <br /> This possible bug is found by an experimental static analysis tool<br /> developed by myself. This tool analyzes the locking APIs to extract<br /> function pairs that can be concurrently executed, and then analyzes the<br /> instructions in the paired functions to identify possible concurrency<br /> bugs including data races and atomicity violations. The above possible<br /> bug is reported, when my tool analyzes the source code of Linux 6.5.<br /> <br /> To fix this possible bug, "urb-&gt;hcpriv = NULL" should be executed with<br /> holding the lock "hsotg-&gt;lock". After using this patch, my tool never<br /> reports the possible bug, with the kernelconfiguration allyesconfig for<br /> x86_64. Because I have no associated hardware, I cannot test the patch<br /> in runtime testing, and just verify it according to the code logic.