CVE-2026-64583

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: udc: bdc: free IRQ and drain funcwakenotify before teardown

The Broadcom BDC UDC driver registers its IRQ handler with devmrequestirq() in bdcudcinit(), so the IRQ is released by devm only after bdcremove() returns. devm releases resources in reverse LIFO order, but bdcremove() runs bdcudcexit() and bdchwexit() -> bdcmemfree() manually before returning: bdcudcexit() tears down individual endpoint objects via bdcfreeep(), while bdchwexit() -> bdcmemfree() frees and NULLs the DMA-coherent status-report ring (bdc->srr.srbds) and kfree()s bdc->bdceparray. Both happen while the IRQ handler (bdcudcinterrupt, requested with IRQFSHARED) remains deliverable in the window up to the post-remove devm free_irq().

On receipt of a shared interrupt in that window, bdcudcinterrupt() dereferences bdc->srr.srbds[bdc->srr.dqpindex] (NULL or freed DMA) and dispatches srhandler callbacks that index into bdcep_array, causing a NULL-deref or use-after-free.

The same window affects the delayedwork bdc->funcwakenotify, which is armed from the IRQ handler via bdcsruspc() -> handlelinkstatechange() -> scheduledelayedwork() and may self-rearm from its own callback bdcfuncwaketimer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdcremove() returns and the bdc structure is devm-freed dereferences freed memory.

Replace devmrequestirq() with requestirq() and add an explicit freeirq(bdc->irq, bdc) in bdcremove(). Clear BDCGIE before freeirq() to stop the device from asserting interrupts, then freeirq() drains any in-flight handler, then canceldelayedworksync() drains the funcwakenotify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdcudcexit() and bdchwexit(). Wire the matching freeirq() into the bdcudcinit() error path so the IRQ is released on probe failure, and route the bdcinitep() failure through err0 instead of returning directly.

This issue was found by an in-house static analysis tool.