CVE-2026-97482: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: gokuudc: avoid NULL deref of dev->driver in INTUSBRESET log
gokuirq() 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 != USBSPEEDUNKNOWN && dev->driver && dev->driver->resume) { spinunlock(&dev->lock); dev->driver->resume(&dev->gadget); ... }
but the very next branch unconditionally dereferences dev->driver when an INTUSBRESET arrives:
if (stat & INTUSBRESET) { ACK(INTUSBRESET); INFO(dev, "USB reset done, gadget %s\n", dev->driver->driver.name); }
If the controller raises INTUSBRESET 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/gokuudc.c:1618 gokuirq() 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 Software
Event History
Frequently Asked Questions
When can this issue be triggered?
It can occur when the Goku USB device controller receives an INT_USBRESET interrupt before a gadget driver is bound or after a previously bound gadget driver has been unbound. In those states, dev->driver is NULL.
What is the impact of triggering the issue?
The interrupt logging path dereferences dev->driver->driver.name despite dev->driver being NULL, causing a NULL-pointer dereference in the kernel.
Does a bound gadget driver avoid the problem?
Yes. The described unsafe dereference is only reached with a NULL gadget driver pointer; the fix makes logging use a placeholder when no gadget driver is bound and does not change behavior when one is bound.
How can I determine whether a system may be exposed?
Systems using the Linux kernel's goku_udc USB gadget controller can be exposed if the controller can receive USB reset interrupts while no gadget driver is bound. Kernel logs or crash reports associated with goku_irq() during an INT_USBRESET event may indicate the condition occurred.