CVE-2026-64583

What the bug is

The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/usb/gadget/udc/bdc/bdc_core.c
drivers/usb/gadget/udc/bdc/bdc_udc.c

What this is

BROADCOM BDC DRIVERMAINTAINERS section matched on drivers/usb/gadget/udc/bdc/ · linux-usb@vger.kernel.org · Maintained

Kernel module

none to look for. The file would have gone into bdc, and Debian does not compile it into that module, so finding bdc in lsmod would say nothing about this CVE.

Check it on the machine

grep -wE 'CONFIG_OF|CONFIG_PCI|CONFIG_USB|CONFIG_USB_BDC_UDC|CONFIG_USB_GADGET|CONFIG_USB_PHY|CONFIG_USB_SUPPORT' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.

• bookworm, trixie, forky, sid, bookworm · linux-6.12n

n

not enabled on any flavour - this release does not build the code

Build switches

CONFIG_OF, CONFIG_PCI, CONFIG_USB, CONFIG_USB_BDC_UDC, CONFIG_USB_GADGET, CONFIG_USB_PHY, CONFIG_USB_SUPPORT

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-08-06 (2 months ago)source

CVSS

7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it

Attack vector

local (AV:L)source

EPSS

0.12%, higher than 1.5% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/usb

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
3.19	5.10.266	eac1107e5467
3.19	5.15.216	0b0b76e31b39
3.19	6.1.183	3fe181952b8a
3.19	6.6.148	1a1d7158420d
3.19	6.12.101	f6fc21ec7ccd
3.19	6.18.42	dcf3e2f16443
3.19	7.1.6	d4964a747171
3.19	7.2	0583f2fbf8f8

Debian advisories