Cloudanix VulnDB

CVE-2026-43180

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

May 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a rarely used Linux USB network driver could let someone with local access crash or possibly take control of an affected machine.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is a local Linux kernel race condition in the kaweth USB Ethernet driver. The driver’s receive-mode callback incorrectly manipulates transmit queue state with netif_stop_queue() and netif_wake_queue(). Under the right timing, the transmit queue can be woken while a transmit USB Request Block is still active, causing the same URB to be submitted twice. This can trigger the kernel warning "URB submitted while active" and may lead to kernel instability, denial of service, or potentially broader memory-safety impact in kernel context. Exploitation requires local access and interaction with an affected kaweth-supported USB network interface; it is not remotely reachable over the network by itself.

Why it matters to the business

Systems using affected Linux kernels with the kaweth USB network driver and compatible USB Ethernet hardware may be exposed to local denial-of-service or privilege-escalation risk. The practical blast radius is likely limited because this is a hardware/driver-specific local issue, EPSS is very low, there is no known exploited-in-the-wild or KEV listing, and no public exploit maturity is reported. However, affected endpoints, appliances, labs, kiosks, or servers that allow untrusted local users or physical USB device access should treat the issue as more urgent because a successful exploit could crash the system or compromise kernel-level security boundaries.

How an attack unfolds

An attacker first needs local code execution on a Linux system where the kaweth USB Ethernet driver is present and an affected Kawasaki USB Ethernet adapter or compatible device is active. The attacker generates transmit activity through the interface while repeatedly triggering receive-mode or multicast configuration changes, for example by changing interface flags, multicast memberships, or related network settings. Because kaweth_set_rx_mode() incorrectly wakes the transmit queue independent of URB completion, a second transmit path can submit the same tx_urb while it is still in flight. The kernel detects this condition as "URB submitted while active"; depending on kernel configuration and runtime behavior, the result may be a warning, interface disruption, kernel crash, or potentially exploitable corruption in kernel context.

How to fix it

Update the Linux kernel to a version that includes the upstream fix removing transmit queue manipulation from kaweth_set_rx_mode(). Because no exact fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or vendor once available. Where immediate patching is not possible, mitigate by unloading or blacklisting the kaweth driver if it is not required, preventing untrusted physical USB device attachment, restricting local shell access, and limiting administrative ability to create or modify network interface multicast settings. If kaweth-supported USB Ethernet adapters are not operationally necessary, disable the driver entirely through kernel module policy or by building kernels without CONFIG_USB_KAWETH.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the kaweth driver and whether the module is loaded. Commands such as `lsmod | grep kaweth`, `modinfo kaweth`, and inspection of `/sys/module/kaweth` can indicate driver presence. Confirm remediation by verifying the installed kernel package version against vendor advisories and, where source validation is possible, confirming that kaweth_set_rx_mode() no longer calls netif_stop_queue() or netif_wake_queue(). After patching or mitigation, reboot into the fixed kernel, verify the old vulnerable kernel is not running with `uname -a`, and confirm the kaweth module is either updated, unavailable, or intentionally blocked. Review kernel logs for absence of new "URB submitted while active" warnings during normal USB Ethernet operation.

Typical attack path

  1. Obtain local access to a Linux system running an affected kernel.
  2. Ensure the kaweth USB Ethernet driver is loaded and a supported USB Ethernet adapter is present or emulated.
  3. Generate outbound traffic through the kaweth-backed network interface.
  4. Repeatedly trigger receive-mode or multicast configuration changes on the interface to invoke kaweth_set_rx_mode().
  5. Race the transmit path so the driver wakes the TX queue before the previous transmit URB has completed.
  6. Cause a duplicate usb_submit_urb() on the active tx_urb, triggering kernel warnings and potentially causing denial of service or kernel-level compromise.

How to detect it

Look for signs of attempted or successful triggering in kernel and system logs rather than network telemetry, because exploitation is local and driver-specific. Relevant sources include `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore artifacts, audit logs showing repeated network interface configuration changes, and USB device attach events. Search for kernel warnings containing "URB submitted while active", call traces involving `usb_submit_urb`, `kaweth_start_xmit`, or `kaweth_set_rx_mode`, and repeated state changes on kaweth-backed interfaces. Also investigate unexpected system crashes, soft lockups, kernel warnings, or reboots that coincide with USB Ethernet attachment, multicast setting changes, or local commands modifying network interface flags. There are no named threat actors or known exploited-in-the-wild campaigns associated with this issue in the provided data.

  • URB submitted while active
  • kaweth
  • kaweth_start_xmit
  • kaweth_set_rx_mode
  • usb_submit_urb
  • /sys/module/kaweth
  • drivers/net/usb/kaweth.c
  • WARNING: CPU:
  • Call Trace:
  • netif_wake_queue
  • netif_stop_queue

What your security team should do

  • Inventory Linux systems for loaded or available kaweth USB Ethernet driver support, especially endpoints and appliances with physical USB exposure.
  • Prioritize kernel updates for systems where untrusted users have local access or where USB devices can be attached without strong controls.
  • If the driver is unnecessary, blacklist or remove kaweth support as a durable mitigation.
  • Restrict physical USB access and disable unused USB networking functionality on sensitive systems.
  • Monitor kernel logs for "URB submitted while active", kaweth-related warnings, crashes, or unexpected reboots.
  • Track Linux distribution advisories for exact fixed kernel package versions and ensure systems boot into the remediated kernel after installation.
  • Because EPSS is low and there is no KEV or known ransomware association, handle through normal kernel patch cycles unless local-user or physical-access risk is high.

The record

In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.

Affected packages

Ecosystem Package Introduced Fixed