ZeroHour

CVE-2026-80947

large

Use-after-free in Linux kernel rtl8xxxu USB Wi-Fi driver on disconnect

CVSS 3.1
7.8 high
EPSS
Published
()
Modified
AI analysis

The Linux kernel's rtl8xxxu driver, which drives many Realtek USB Wi-Fi adapters, contains a use-after-free: rtl8xxxu_stop() cancels its other work items but never cancels rx_urb_wq, so a worker queued during a burst of RX traffic can run after rtl8xxxu_disconnect() has freed the driver's private data via ieee80211_free_hw(). The race window opens under active RX traffic that pushes the pending-URB list past its watermark followed by an interface stop or device unplug — conditions a local, low-privileged attacker can attempt to trigger to corrupt freed kernel memory. Successful exploitation gives high confidentiality, integrity, and availability impact (CVSS 3.1: 7.8), i.e., plausible local privilege escalation or a system crash. Any system running an unfixed kernel with a Realtek USB Wi-Fi adapter handled by rtl8xxxu is affected, which is typical of Linux desktops, laptops, and single-board computers using common USB dongles. The flaw was found by static analysis; no public PoC exists, it is not in CISA's KEV, and no exploitation in the wild is known.

What to do: Apply distribution kernel updates as soon as they backport the rtl8xxxu fix and confirm the rtl8xxxu rx_urb_wq use-after-free patch appears in the changelog. On shared or multi-user machines where the USB dongle is not needed, unplug the adapter or blacklist the rtl8xxxu module to eliminate the race. Watch dmesg for oopses in rtl8xxxu_rx_urb_work()/rtl8xxxu_submit_rx_urb() around disconnect events as evidence the race is being hit.

Affected
Linux kernel (drivers/net/wireless/realtek/rtl8xxxu Realtek USB Wi-Fi driver)Kernel versions prior to the fix commit; the advisory does not state specific version numbers. Fixed by moving schedule_work() under the rx_urb_lock shutdown ch
Estimated exposure
large≈100,000–1,000,000 Linux systems with Realtek USB Wi-Fi adapters running vulnerable kernels (rough order-of-magnitude estimate) — The rtl8xxxu driver ships in mainline kernels and Realtek-based USB Wi-Fi dongles are among the most common adapters on Linux desktops and single-board computers, but no public install telemetry exists for the driver, so this is a…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop rtl8xxxu arms rx_urb_wq from the RX completion path: rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which queues it on rx_urb_pending_list and, once the list grows past RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq. The worker rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(), which anchors it on rx_anchor and dereferences priv->udev. rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog, update_beacon_work) but never cancels rx_urb_wq, so a worker armed during the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect. There are two teardown races to close: * rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock but called schedule_work() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedule_work() after rtl8xxxu_stop() had set shutdown and cancel_work_sync() had already returned, arming the worker to run after the teardown. Move schedule_work() under the same !shutdown branch so the arming decision is atomic with the shutdown check. * rtl8xxxu_rx_urb_work() anchors every URB it drained back onto rx_anchor through rtl8xxxu_submit_rx_urb(). A worker still running when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a URB that escaped the kill. In rtl8xxxu_stop(), call cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is drained first. After priv->shutdown is set under rx_urb_lock, completions can no longer queue rx_urb_wq. cancel_work_sync() then drains the last queued or running worker, and the following usb_kill_anchored_urbs() kills the URBs it may have submitted. rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw() guarantees .stop() runs for a live interface before ieee80211_free_hw() frees priv. The probe error path needs no cancel: rx_urb_wq is INIT_WORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211_register_hw() succeeds. This bug was found by static analysis.

Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.