CVE-2026-80941

What it actually does

A kernel-space memory leak in the Linux rtw88 Wi-Fi driver: when rtw_hci_tx_write() fails, rtw_txq_push_skb() returns without freeing the associated sk_buff. Each failed transmit therefore permanently consumes kernel memory (sk_buff and associated payload buffers) until the host is rebooted. Repeated failures can exhaust slab/kmalloc memory and trigger the OOM killer or a kernel panic, producing a denial-of-service condition on systems using Realtek rtw88-based adapters.

Why it matters to the business

Hosts that use Realtek rtw88 Wi-Fi (laptops, embedded devices, and some APs) can gradually lose available memory and become unstable or unresponsive, causing wireless outages, unexpected reboots, and loss of in-memory work. Likelihood of in-the-wild abuse is currently low: EPSS is 0.0022 and flat over 30 days, the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none. The CVE is about 20 days old with no listed affected-product inventory or vendor fixed-version mapping, so operational risk is mainly unpatched Linux kernels that load rtw88 rather than a mass-exploitation event.

How an attack unfolds

An attacker who can cause the rtw88 transmit path to fail (local process with network access, a poorly behaving peer, or conditions that make the HCI write fail) repeatedly queues frames that are dequeued in rtw_txq_push() and handed to rtw_txq_push_skb(). On each HCI write failure the skb is leaked instead of freed. Over time kernel memory grows without a corresponding free, until allocation failures, OOM, or a crash take the system down. There are no public exploits, named threat actors, or ransomware campaigns associated with this flaw; it is a local/adjacent availability issue rather than remote code execution.

How to fix it

Apply the upstream Linux kernel fix that frees the skb on the rtw_txq_push_skb() error path when rtw_hci_tx_write() fails, then reboot into the patched kernel so the rtw88 module is replaced. Prefer distribution kernel packages that include this rtw88 memory-leak fix; if a distro package is not yet available, track the stable-tree commit for wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() and backport or upgrade to a kernel series that contains it. No per-package fixed versions were published with this record, so confirm the patch is present in your vendor’s kernel changelog. As a temporary mitigation on systems that do not need the adapter, unload or blacklist rtw88 (and related rtw88_* HCI modules) or use a different NIC until the patched kernel is deployed. Compiling a custom kernel is unnecessary if a vendor update already includes the fix.

How to confirm the fix worked

Confirm the running kernel includes the rtw88 skb-free-on-error change (vendor advisory, kernel changelog, or inspection of rtw_txq_push_skb() in the built rtw88 source). After upgrade, reboot and verify the new kernel and rtw88 module versions are loaded (uname, modinfo rtw88). On a test host, exercise Wi-Fi transmit under load and confirm kernel slab usage for skbuff-related caches remains stable and that dmesg/journal show no unbounded memory-growth or OOM patterns tied to rtw88. Inventory remaining unpatched kernels that have rtw88 loaded.

Typical attack path

1. Identify a Linux host whose wireless stack uses the rtw88 driver (Realtek 802.11ac USB/PCIe adapters).
2. Obtain local or adjacent ability to generate sustained transmit traffic or otherwise induce rtw_hci_tx_write() failures.
3. Cause repeated TX-queue push operations so dequeued skbs take the error path in rtw_txq_push_skb().
4. Allow leaked sk_buffs to accumulate in kernel memory.
5. Wait for slab/page exhaustion, OOM killer activity, wireless interface failure, or host crash.

How to detect it

There are no public exploits or actor-specific playbooks, so look for effects of a kernel memory leak rather than a unique payload. On Linux hosts with rtw88 loaded, review kernel logs (dmesg, journalctl -k) around OOM killer events, allocation failures, and wireless transmit errors; correlate with unexplained growth in slab caches used by sk_buff (for example skbuff_head_cache) via /proc/slabinfo, vmstat, or memory cgroup metrics. Check whether rtw88/rtw88_pci/rtw88_usb/rtw88_sdio were loaded at the time of memory pressure. Network telemetry will not show a distinctive C2 pattern. A single crash without progressive kernel memory growth is weak evidence of this bug; sustained sk_buff growth coinciding with TX failures on rtw88 is more suggestive. Absence of these artifacts does not prove the host was never exposed—only that a leak-driven DoS may not have completed.

• rtw88
• rtw_txq_push_skb
• rtw_hci_tx_write
• Out of memory: Killed process
• skbuff_head_cache
• modprobe rtw88
• rtw88_pci
• rtw88_usb
• rtw88_sdio

What your security team should do

• Prioritize kernel updates on Linux endpoints and appliances that actually load rtw88; deprioritize hosts without Realtek rtw88 hardware.
• Treat this as a low-urgency DoS patch (EPSS ~0.0022, not KEV, no known exploit) unless you operate large fleets of always-on rtw88 devices.
• Blacklist or unload rtw88 only where wireless is unused and a kernel update cannot be applied quickly.
• Watch distribution security trackers for the exact kernel package version that contains the rtw_txq_push_skb() leak fix.
• Add kernel memory/OOM monitoring on rtw88 hosts so a leak would be noticed even before the patch lands.
• Do not allocate incident-response resources as if this were an RCE or KEV item unless new exploitation evidence appears.