What happened
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->resume) { spin_unlock(&dev->lock); dev->driver->resume(&dev->gadget); ... } but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: if (stat & INT_USBRESET) { ACK(INT_USBRESET); INFO(dev, "USB reset done, gadget %s\n", dev->driver->driver.name); } If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.
Affected versions
Linux: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 through before 10d7fc3008d5b7ec03af8e08927f1d090014c2af (git); 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 through before 28d78783a871cdb7a637dcb72452ff7d303430ae (git); 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 through before 5bf5e3fba9bc7dfd69701521dbe9809f8ccbdb02 (git); 2.6.12 Fixed: See vendor advisory.
Why it matters
Review the vendor advisory and exposure of the affected product to determine operational impact.
Detection & mitigation
- Apply vendor-provided updates or mitigations.
- Review affected product exposure and access logs.
Public PoC references
No public PoC reference has passed the current publication threshold.