CVE-2026-80940

What it actually does

The Linux kernel rtw88 PCI Wi-Fi driver leaks PCI resources when NAPI initialization fails during probe. rtw_pci_probe() allocates PCI resources via rtw_pci_setup_resource() before NAPI setup; if rtw_pci_napi_init() fails, the error path jumps to err_pci_declaim and skips rtw_pci_destroy(), so mappings and related allocations are never released. Repeated failed probes can accumulate leaked PCI/kernel resources and leave the adapter in an inconsistent state, producing a local denial-of-service condition against wireless networking and kernel resource pools.

Why it matters to the business

Impact is limited to Linux systems that use Realtek rtw88 PCI wireless adapters (laptops, embedded devices, and appliances). Exploitation probability is very low (EPSS about 0.002 and flat over 30 days), the issue is not in CISA KEV, there is no ransomware association, and exploit maturity is none, so organizational urgency is low. Residual operational risk is local resource exhaustion or loss of Wi-Fi if probe repeatedly fails, typically requiring a reboot or driver rebind to recover rather than a broad outage or data breach.

How an attack unfolds

This is a local cleanup defect on a failed driver-probe path, not a remote packet-triggered flaw and not known to be used by named threat actors. An attacker who already has local influence over driver bind/unbind (module load, PCI rescan, or repeated probe of an rtw88 PCI function) must cause rtw_pci_napi_init() to fail after PCI resources have been allocated. The broken error path then skips destruction of those resources. Forcing that failure repeatedly can exhaust PCI mappings or related kernel allocations and deny or degrade wireless service. No public exploit, KEV listing, or in-the-wild campaign is associated with this issue.

How to fix it

Apply the upstream Linux kernel fix that adds a dedicated NAPI-setup failure cleanup label so probe always calls rtw_pci_destroy() after rtw_pci_setup_resource() succeeds. Upgrade to a vendor or distribution kernel that includes that rtw88 PCI resource-leak patch (no specific fixed version numbers were published with this record). If a packaged kernel is not yet available, request a backport of the rtw88 pci probe error-path cleanup. Until patched, avoid repeated bind/unbind or forced re-probe of rtw88 PCI devices and restrict unprivileged module loading. Hosts without rtw88 PCI hardware are not affected.

How to confirm the fix worked

Confirm the running kernel changelog, distro advisory, or git history includes the rtw88 PCI NAPI-failure cleanup (dedicated destroy path instead of jumping straight to err_pci_declaim). After upgrade, verify the rtw88 PCI driver still probes cleanly (dmesg/journal, lspci, interface comes up). On lab hardware only, confirm that a failed NAPI init no longer leaves PCI mappings behind (compare lspci -vv / iomem before and after a failed probe). Inventory images and live kernels for rtw88 PCI support; systems without that driver or without matching hardware can be marked not exposed.

Typical attack path

1. Obtain local access or equivalent control over driver bind/unbind on a Linux host with an rtw88 PCI Wi-Fi adapter
2. Cause the rtw88 PCI driver to probe (module load, device rescan, or reboot into a failing init path)
3. Induce NAPI initialization failure after PCI resources have already been allocated
4. Rely on the skipped destroy path so PCI resources remain allocated
5. Repeat failed probes to accumulate leaked resources and deny or degrade Wi-Fi / kernel resource availability

How to detect it

There is no public exploitation and no named actor activity to hunt. Look for evidence the broken probe path actually ran rather than for malware artifacts: kernel logs (dmesg, journald/kern.log) showing rtw88 PCI probe or NAPI init failure, followed by repeated rtw88 module load/unload, PCI rescan, or unexplained growth in PCI mappings / kernel memory on hosts with rtw88 PCI adapters. Correlate with local privilege use, unexpected modprobe/rmmod of rtw88, or operator-driven driver rebinds. Absence of those logs does not prove the bug was never hit; presence of probe-failure logs alone is not proof of attack.

What your security team should do

• Treat as low urgency: not KEV, EPSS ~0.002 and unchanged over 30 days, no known exploit or ransomware use
• Inventory Linux endpoints and appliances for Realtek rtw88 PCI Wi-Fi (rtw88 PCI driver / matching adapters) and deprioritize hosts without that hardware
• Patch to a kernel that includes the rtw88 probe error-path destroy fix when vendor/distro packages ship it; request backports for long-life kernels
• Until patched, restrict local module load/unload and avoid operational procedures that repeatedly rebind rtw88 PCI devices
• Track vendor kernel advisories; no emergency out-of-band response is warranted given current threat data