CVE-2023-52855 in Linux
Zusammenfassung
von VulDB • 07.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
usb: dwc2: Behebung einer möglichen NULL-Zeiger-Dereferenzierung durch Treiber-Concurrency (Nebenläufigkeit)
In _dwc2_hcd_urb_enqueue() wird „urb->hcpriv = NULL“ ausgeführt, ohne die Sperre „hsotg->lock“ zu halten. 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); // Verwendung von urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags);
Wenn _dwc2_hcd_urb_enqueue() und _dwc2_hcd_urb_dequeue() gleichzeitig ausgeführt werden, kann die NULL-Prüfung von „urb->hcpriv“ vor der Zuweisung „urb->hcpriv = NULL“ erfolgen. Nachdem urb->hcpriv auf NULL gesetzt wurde, kann es im Funktionsaufruf an dwc2_hcd_urb_dequeue() verwendet werden, was zu einer NULL-Zeiger-Dereferenzierung führen kann.
Dieser mögliche Fehler wurde von einem experimentellen statischen Analysewerkzeug gefunden, das ich selbst entwickelt habe. Dieses Werkzeug analysiert die Locking-APIs (Sperren-Schnittstellen), um Funktionspaare zu extrahieren, die gleichzeitig ausgeführt werden können, und analysiert anschließend den Code in diesen gepaarten Funktionen, um mögliche Concurrency-Fehler einschließlich Data Races (Datenwettläufen) und Verletzungen der Atomizität zu identifizieren. Der oben genannte Fehler wurde gemeldet, als mein Tool den Quellcode von Linux 6.5 analysierte.
Um diesen möglichen Fehler zu beheben, sollte „urb->hcpriv = NULL“ unter Halten der Sperre „hsotg->lock“ ausgeführt werden. Nach Anwendung dieses Patches meldet mein Tool mit der Kernel-Konfiguration allyesconfig für x86_64 keine möglichen Fehler mehr. Da ich über keine zugehörige Hardware verfüge, kann ich den Patch nicht in Runtime-Tests testen und habe ihn lediglich anhand der Code-Logik verifiziert.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.