CVE-2026-43255

What it actually does

This is a local availability flaw in the Linux kernel libertas USB Wi-Fi driver. The driver can resubmit a transmit URB before the previous USB transfer has completed, causing the kernel USB subsystem to warn with "URB submitted while active". On systems configured to treat kernel warnings as fatal, or where repeated driver faults destabilize the device/host, this can result in a denial of service through a kernel warning, driver disruption, or system crash. The issue does not provide confidentiality or integrity impact and does not enable remote code execution.

Why it matters to the business

Affected Linux systems using the libertas USB Wi-Fi driver may experience local denial of service, especially during rapid device initialization or firmware loading. The practical risk is highest for endpoints, appliances, embedded systems, or legacy deployments that use Marvell/Libertas USB wireless hardware and have kernel panic-on-warning behavior enabled. Because this is not in the CISA KEV catalog, has no known mature exploit, and has a very low EPSS score, broad internet-scale exploitation is unlikely; remediation should still be included in normal kernel maintenance to prevent avoidable outages.

How an attack unfolds

An attacker first needs local access to a system where the vulnerable Linux kernel and libertas USB Wi-Fi driver are present and usable. The attacker then triggers repeated or rapid driver transmit activity, such as device initialization, reset, or firmware-loading paths that call usb_tx_block() before the existing transmit URB has completed. In the vulnerable implementation, the driver attempts to submit the same URB while it is still active. The USB core detects this unsafe reuse and emits the warning "URB submitted while active". If the host is configured to panic on kernel warnings, or if repeated driver errors disrupt system stability, the result can be a local denial of service. The patched implementation serializes use of the URB by killing any active URB before resubmission.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the libertas driver fix adding serialization before URB resubmission. No exact fixed package versions were provided in the input, so use vendor advisories, distribution security trackers, or upstream stable kernel changelogs to identify the corrected kernel for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the libertas driver if it is not required, removing affected USB Wi-Fi hardware, preventing untrusted local users from triggering device reset/reload workflows, and reviewing whether panic_on_warn is enabled on systems where availability is critical.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream libertas fix for usb_tx_block() serialization, specifically ensuring the code path calls usb_kill_urb() before reusing the transmit URB. Validate that systems no longer log "URB submitted while active" from the libertas USB Wi-Fi path during device initialization, firmware loading, reconnect, or stress testing. Check whether the libertas driver is loaded with tools such as lsmod, modinfo, dmesg, and distribution package metadata. For mitigations, verify that the libertas module is blocked or absent where the hardware is not needed, and confirm the host remains stable during repeated USB Wi-Fi attach/detach or firmware reload testing.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the libertas USB Wi-Fi driver available.
2. Confirm that compatible libertas USB Wi-Fi hardware or driver paths are present.
3. Trigger rapid driver activity, such as repeated device initialization, reset, reconnect, or firmware-loading behavior.
4. Cause usb_tx_block() to reuse cardp->tx_urb while the URB is still active.
5. Force the kernel USB subsystem to emit the warning "URB submitted while active".
6. If kernel warning handling or repeated driver instability permits it, cause a denial of service through a crash, panic, or loss of wireless functionality.

How to detect it

Look for evidence in kernel and system logs that the USB subsystem warned about an active URB submission in the libertas driver path. Useful sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and endpoint telemetry that captures kernel warnings or panics. Search for warning strings around times of USB Wi-Fi initialization, firmware loading, device reset, disconnect/reconnect, or local user activity involving network hardware. Investigate whether panic_on_warn was enabled and whether a warning was followed by reboot, kernel panic, service outage, or loss of wireless connectivity. Because there are no public reports of exploitation and the bug is a local denial-of-service condition, detection should focus on kernel warning artifacts and suspicious repeated local triggering rather than remote network indicators.

• URB submitted while active
• usb_tx_block
• libertas
• wifi: libertas
• cardp->tx_urb
• usb_submit_urb
• usb_kill_urb
• WARNING in usb_tx_block
• kernel: WARNING
• panic_on_warn
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Inventory Linux systems that load or can load the libertas USB Wi-Fi driver, prioritizing embedded, appliance, kiosk, and endpoint fleets using USB wireless adapters.
• Patch affected systems through the normal kernel update process once vendor-fixed builds are available.
• If libertas hardware is not required, disable or blacklist the libertas driver as a compensating control.
• Review kernel panic-on-warning settings on availability-sensitive systems because this flaw is most disruptive when warnings can crash the host.
• Monitor kernel logs for "URB submitted while active", "usb_tx_block", and libertas-related warnings to identify potentially affected or unstable systems.
• Treat confirmed occurrences as reliability and local-abuse signals rather than evidence of remote compromise unless accompanied by suspicious local activity.
• Because EPSS is low and there is no KEV listing or known exploit maturity, prioritize remediation based on driver presence and operational criticality rather than broad emergency response.