CVE-2026-43425

What it actually does

This is a local denial-of-service flaw in the Linux kernel mdc800 USB image driver. The driver submits a USB Request Block (URB) for a device read and waits for completion, but when the wait times out it returns without cancelling the still-active URB. A later read can submit the same URB again while it is already in flight, triggering the kernel warning path in usb_submit_urb() with the message "URB submitted while active". On systems configured to panic on kernel warnings, or where repeated warnings destabilize the driver/kernel, this can cause a host crash or loss of availability. The issue does not directly provide confidentiality or integrity impact and requires local privileges sufficient to access the affected USB device/driver.

Why it matters to the business

A local user or process with access to the affected USB imaging driver can potentially crash or destabilize a Linux system, causing service interruption, reboot, or downtime. The risk is highest on workstations, kiosks, embedded systems, industrial hosts, or servers that allow local user access and have the mdc800 driver available or loaded. The current EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely; however, systems that enable panic-on-warn or expose USB device access to untrusted users should treat this as a meaningful availability risk.

How an attack unfolds

An attacker first needs local access to a Linux system where the vulnerable kernel includes the mdc800 USB image driver and where the attacker can interact with the associated USB device interface. The attacker causes a read operation against the mdc800 device to wait for a device response that does not arrive before the timeout. Because the vulnerable driver returns without killing the pending download URB, the URB remains active. The attacker then performs another read, causing the driver to submit the same URB again. The kernel detects that the URB is already active and emits a WARN from usb_submit_urb(), typically containing "URB submitted while active". If kernel warning handling is configured to panic, or if repeated triggering degrades the driver or kernel state, this results in a local denial of service.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for the mdc800 driver timeout path, specifically the change that kills the download URB when wait_event_timeout() indicates a timeout. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the first fixed build for each distribution. Where immediate patching is not possible, mitigate by disabling or unloading the mdc800 driver if not required, blacklisting the module, restricting local access to USB imaging devices, applying USB device authorization controls, and limiting local interactive access to trusted users. If operationally acceptable, avoid configurations where non-critical kernel WARN conditions immediately panic the host, while recognizing that changing panic behavior is a resilience measure and not a substitute for patching.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel version is older than the vendor-fixed kernel and whether the mdc800 driver is present, built in, or loaded. Useful checks include reviewing vendor kernel package changelogs for the mdc800 timeout fix, running module checks such as lsmod or modinfo for mdc800 where applicable, and checking kernel configuration for the mdc800 USB image driver. Confirm remediation by verifying the installed kernel package includes the fix, rebooting into the fixed kernel, and ensuring the vulnerable module is not loaded or is blacklisted where mitigation was chosen. After remediation, monitor kernel logs during normal operation for absence of "URB submitted while active" warnings involving mdc800 or usb_submit_urb(). Avoid destructive proof-of-concept testing on production systems because triggering the bug may crash the host.

Typical attack path

1. Gain local shell, local code execution, or another way to run a process under a user account on the target Linux system.
2. Confirm that the vulnerable kernel contains the mdc800 USB image driver and that the attacker can access the relevant USB device node or driver interface.
3. Trigger a read operation against the mdc800 device where the device does not complete the transfer before the driver's timeout.
4. Allow the vulnerable code path to return without cancelling the still-active download URB.
5. Issue a subsequent read so the same URB is submitted while already active.
6. Cause the kernel to log a WARN from usb_submit_urb(), and on susceptible configurations trigger a crash, panic, or persistent availability degradation.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, crash dumps, and reboot records for warnings or panics involving the mdc800 driver and USB URB submission. Primary sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg history, pstore/ramoops records, kdump/vmcore artifacts, and endpoint telemetry capturing kernel oops or panic events. Look for the exact warning "URB submitted while active", stack traces referencing usb_submit_urb() and mdc800_device_read(), repeated read activity against the mdc800 device shortly before a crash, unexpected host reboots, and panic records that follow a kernel WARN. Because the issue is local and device-driver-specific, correlate kernel events with local login/session logs, process accounting, auditd records for device-node access, and USB attach/detach events. There are no network IOCs for this vulnerability unless exploitation is launched through a remote shell or management channel already present on the host.

• URB submitted while active
• usb_submit_urb
• mdc800_device_read
• mdc800
• download_urb
• WARNING: CPU
• kernel: WARNING
• kernel: BUG
• kernel panic
• panic_on_warn
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• /sys/module/mdc800
• /proc/config.gz
• CONFIG_USB_MDC800
• modprobe mdc800

What your security team should do

• Prioritize patching Linux systems that allow local user access, use USB devices, run kiosk/desktop/embedded workloads, or have panic-on-warn enabled.
• Inventory systems for the mdc800 driver using kernel configuration, module inventory, and endpoint management telemetry.
• Apply the vendor-fixed kernel as soon as available and reboot into the fixed kernel; verify that older vulnerable kernels are not still selected by the bootloader.
• If the driver is not needed, unload and blacklist mdc800 and enforce USB device control policies to prevent unnecessary driver exposure.
• Restrict permissions on USB device nodes and avoid granting untrusted users access to raw or specialized USB device interfaces.
• Add detections for kernel log messages indicating "URB submitted while active", mdc800 activity, USB URB warnings, and unexpected kernel panics following local USB device access.
• Review systems that recently crashed or rebooted unexpectedly for kernel WARN/oops traces involving usb_submit_urb() or mdc800.
• Because this is not KEV-listed, has no known ransomware association, and has low EPSS, handle through normal kernel vulnerability management unless affected systems are safety-critical or highly availability-sensitive.