bdc driver, the result can be a kernel NULL-pointer dereference or use-after-free during device removal, driver unload, or a failed probe—conditions that can crash the machine and, depending on exploitation of the memory-safety flaw, carry broader local-security consequences.The Linux kernel CVE record lists fixed versions 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5, with kernel.org assigning a CVSS 3.1 score of 7.8 High. NVD published the record on August 6, 2026 and updated it on August 8, but has not supplied its own CVSS assessment. That distinction matters for patch dashboards: the only current severity vector is the Linux CNA’s rating, which requires local privileges and does not describe a remotely reachable USB-host attack.
For Windows users, this is not a Windows kernel vulnerability. It is also not a defect in the ordinary USB host stack used when a PC connects keyboards, storage drives, phones, or webcams. Windows 11, Windows Server, and standard Windows hardware installations do not ship or load the Linux
bdcdriver. The relevant Windows-adjacent case is a machine running Linux through WSL 2, a dual-boot Linux installation, or a custom appliance kernel—and even then, only if the Broadcom BDC gadget-controller driver is enabled and bound to supported hardware.
The Bug Is in Driver Removal, Not USB Enumeration
The vulnerable component is the Broadcom Device Controller, or BDC, USB gadget driver. In Linux terminology, a gadget controller presents the machine as a USB peripheral to another system; it is not the same role as the host controller that accepts a USB flash drive or external keyboard.
The Kernel Driver Database identifies the option as
CONFIG_USB_BDC_UDC, a tristate configuration that builds the
bdcmodule. It depends on
CONFIG_USB_GADGETand DMA support. In practical terms, a general-purpose Linux server or desktop kernel can contain the source code without ever exposing the vulnerable path: it needs the driver compiled in or available as a module, compatible Broadcom BDC hardware, and the driver to be active.
That is the first important narrowing of the CVE’s broad version range. Kernel.org marks the flaw as present from Linux 3.19 onward until the listed stable fixes, but kernel version alone is not an exposure test. A distro kernel can be in an affected version range and still be operationally unaffected if
CONFIG_USB_BDC_UDCis disabled, if the
bdcmodule is absent, or if the system has no matching device-controller hardware.
The vulnerability appears while the driver is coming apart. Before the fix, initialization used
devm_request_irq(), which made the device-resource framework responsible for releasing the interrupt handler. That release happens only after the driver’s
bdc_remove()routine returns. But
bdc_remove()itself manually tears down USB endpoint objects, frees a DMA-coherent status-report ring, and releases the endpoint array before returning.
That ordering creates a small but real race: the hardware can still signal an interrupt after those structures have been freed. The interrupt routine can then access either cleared or already-released memory. The CVE description specifically calls out access to the status-report ring and callbacks that index into the freed endpoint array.
The defect is therefore not a matter of a malformed USB device being parsed incorrectly. It is a lifetime-management problem in the driver’s own shutdown sequence. An attacker would need a route to cause or influence the relevant local driver and hardware state, which is consistent with kernel.org’s
AV:L/PR:LCVSS vector.
The Delayed Work Item Makes the Failure Window Last Longer
The interrupt race was only half the cleanup problem. The BDC interrupt path can schedule delayed work called
func_wake_notify, and the delayed-work callback can schedule itself again. According to the kernel.org description carried by NVD, the driver previously had no cancellation path for that work.
That means the hazard could survive beyond the immediate interrupt window. A queued callback could execute after
bdc_remove()had returned and after device-managed cleanup had freed the driver’s own structure. At that point, the delayed-work callback would dereference memory that no longer belongs to the driver.
The fix changes ownership and ordering rather than attempting to suppress a symptom. It replaces
devm_request_irq()with an explicit
request_irq(), then does the following before endpoint and DMA teardown:
- It clears the controller’s global interrupt-enable state so the hardware stops asserting new interrupts.
- It calls
free_irq()to unregister the handler and wait for any handler already in flight. - It calls
cancel_delayed_work_sync()to ensurefunc_wake_notifycannot execute or requeue itself after the driver’s memory is released.
The patch also repairs failure handling during initialization. If endpoint setup fails after the interrupt has been acquired, the error path now frees the IRQ rather than returning directly and relying on later device-managed cleanup. That is a meaningful detail: teardown bugs often reappear on error paths after a clean remove path has been fixed.
Kernel.org says the issue was found by an in-house static-analysis tool. No public exploit, crash report campaign, or independent exploitation report was identified in the initial public record. Administrators should treat it as a patched kernel-memory-safety flaw, not as evidence that Broadcom USB devices in general are under active attack.
Why the Hardware Scope Is Narrow but Worth Checking
The BDC driver supports Broadcom USB 3.0 device-controller IP, including platform-device configurations described by
brcm,bdcand related device-tree compatible strings. The Kernel Driver Database also records historical PCI support for Broadcom vendor ID
14e4, device ID
1570, identified there as a 720p FaceTime HD Camera.
That PCI identifier should not be turned into a blanket claim that every Mac camera, every Broadcom adapter, or every laptop containing a Broadcom component is vulnerable. The driver’s exposure depends on the local kernel configuration and whether the hardware is attached through the BDC driver. A Broadcom Wi-Fi chip, Bluetooth adapter, Ethernet controller, or ordinary USB peripheral is unrelated to this CVE.
For Linux administrators, the quickest inventory starts with the kernel configuration:
grep -E 'CONFIG_USB_BDC_UDC|CONFIG_USB_BDC_PCI' /boot/config-$(uname -r)On distributions that expose the running configuration through
/proc/config.gz, the equivalent is:
zgrep -E 'CONFIG_USB_BDC_UDC|CONFIG_USB_BDC_PCI' /proc/config.gzA value of
# CONFIG_USB_BDC_UDC is not setremoves the driver from the kernel build. A value of
CONFIG_USB_BDC_UDC=mmeans it is available as a module, while
=ymeans it is built into the kernel. On systems where it is modular,
modinfo bdcand
lsmod | grep '^bdc'can establish whether the module exists and is presently loaded.
A configuration hit should lead to hardware and deployment review, not immediate assumptions of exploitation. Embedded products and custom Linux images that use USB gadget functionality deserve the fastest review, particularly where hardware can be removed, reprobed, reset, or exposed to local administrative users. Fleet operators using stock server kernels should still check the configuration, but they should not turn a driver-specific CVE into an emergency reboot of every Linux virtual machine.
Fixed Stable Kernels Are the Clean Remediation Path
Kernel.org’s affected-version data says the BDC driver has existed since Linux 3.19, but the resolved stable lines currently begin at Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The upstream development fix is present in 7.2-rc5. Systems pinned to older end-of-life kernel series will not receive one of those stable releases and need either a vendor backport, an upgrade to a supported kernel line, or a narrowly reviewed backport of the relevant patch.
The practical remediation order is straightforward:
- Confirm whether
CONFIG_USB_BDC_UDCis enabled and whether affected BDC hardware exists. - Install the vendor kernel update that incorporates the applicable stable fix.
- Reboot into the new kernel, because the vulnerable interrupt and workqueue code is resident kernel code.
- If an immediate update is impossible, disable or avoid loading the
bdcmodule where it is not required, while recognizing that this is a temporary exposure reduction rather than a substitute for a corrected kernel.
The CVE record’s broad “Linux” product label is technically accurate but operationally incomplete. The actionable population is much smaller: Linux systems running the Broadcom BDC USB gadget driver on matching hardware. Those systems should move to their vendor’s kernel containing the fix; everyone else should verify the driver configuration before treating CVE-2026-64583 as an active fleet-wide incident.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:43 AM UTC
- Security advisory: MSRC
Published: August 9, 2026 at 8:43 AM UTC
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: code.googlesource.com
- Related coverage: code.googlesource.com
- Related coverage: linux.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: kernel.googlesource.com
