Cloudanix VulnDB

CVE-2026-80942

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in a Linux Wi-Fi driver can waste system memory if the driver fails while starting, which might knock out wireless networking or force a restart until the system is updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
None

What it actually does

The Linux kernel Realtek rtlwifi RTL8192DU driver leaks kernel memory when rtl92du_init_sw_vars() hits an error after rtl92du_init_shared_data() has allocated shared data. Those allocations are not released on the failing paths, so kernel heap/slab memory remains occupied until reboot. Repeated initiation of that error path can exhaust kernel memory and produce allocation failures, wireless-stack instability, or a host-wide denial of service. The defect is an availability issue only; it does not by itself provide memory corruption, arbitrary code execution, or privilege escalation.

Why it matters to the business

Operational risk is low for most organizations. Exploit probability is very small (EPSS about 0.002 and unchanged over 30 days), the issue is not in CISA KEV, no ransomware use is reported, and public exploit maturity is none. Only Linux systems that load the RTL8192DU Wi-Fi driver are in scope; hosts without that adapter or with the module blacklisted are unaffected. Worst realistic outcome is wireless outage or, if the leak is stressed, memory pressure requiring reboot. Treat this as a routine kernel update, not an emergency change, unless those adapters are widely deployed in critical wireless infrastructure.

How an attack unfolds

A local actor who can cause the RTL8192DU driver to initialize and then fail after shared-data allocation leaves kernel memory unfreed. Repeating that init-and-fail cycle grows unreclaimed allocations until the kernel is memory-starved and the wireless stack or the host becomes unavailable. The condition is local and availability-only: there is no known remote trigger, no public exploit, and no associated APT, campaign, or ransomware activity. Accidental driver load failures can produce the same leak without an attacker.

How to fix it

Install a Linux kernel from the distribution or upstream that includes the rtlwifi rtl8192du fix: call rtl92du_deinit_shared_data() on error paths in rtl92du_init_sw_vars(). Reboot so the patched driver is loaded. Advisory metadata does not list exact package versions, so use vendor changelogs or kernel git history for that patch. If a patched kernel is not yet available and the adapter is not required, unload rtl8192du and blacklist it, or use a different NIC. No configuration workaround corrects the missing free.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the rtl92du_deinit_shared_data() error-path call in rtl92du_init_sw_vars(). Check whether rtl8192du is loaded and whether RTL8192DU hardware is present. After patching and reboot, load and unload the driver and watch kernel memory (kmemleak, slab usage, /proc/meminfo) for growth tied to that module. Hosts that never load rtl8192du can be marked not exposed.

Typical attack path

  1. Identify a Linux host that has RTL8192DU hardware or the rtl8192du module available
  2. Obtain local ability to load the driver or otherwise run rtl92du_init_sw_vars()
  3. Cause initialization to allocate shared data and then fail before teardown runs
  4. Repeat the failing initialization until kernel memory is exhausted
  5. Observe wireless failure, allocation errors, or host instability as the denial-of-service outcome

How to detect it

No in-the-wild exploitation, named threat actors, or ransomware use is known, so compromise hunting is optional and low yield. Review kernel logs around driver load for rtl8192du/rtlwifi initialization failures coinciding with unexplained slab/kmemleak growth or OOM kills, repeated module load/unload, and wireless interface flaps without a hardware explanation. kmemleak or similar reports attributing leaks to rtl92du_init_shared_data are the strongest artifact. There is no distinctive network traffic, file drop, process name, or registry-style IOC; absence of these signs does not prove the leak was never hit.

What your security team should do

  • Inventory Linux endpoints and images for RTL8192DU hardware and a loaded or packaged rtl8192du/rtlwifi module
  • Apply distribution kernel updates that include the rtl8192du error-path free on the normal patch cadence; no KEV due date applies
  • Blacklist rtl8192du on systems that do not need that adapter
  • Watch kernel OOM, kmemleak, and rtlwifi/rtl8192du init-failure logs for memory-pressure symptoms
  • Revisit only if EPSS, KEV, or exploit-maturity status changes; current likelihood of attack is very low

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: rtl8192du: Fix possible memory leak in rtl92du_init_sw_vars() The memory allocated inside rtl92du_init_shared_data() is not freed in any of the subsequent error paths in rtl92du_init_sw_vars(). Fix that by adding a call to rtl92du_deinit_shared_data() in the error path.

Affected packages

Ecosystem Package Introduced Fixed