CVE-2026-53258

What it actually does

This is a Linux kernel memory leak in the cfg80211 Wi-Fi subsystem. When split 6 GHz scanning is attempted and cfg80211_scan() fails, the internal scan request object rdev->int_scan_req is not released because the normal cleanup path exits early when rdev->scan_req is NULL. Repeatedly triggering this failure can consume kernel memory over time, potentially degrading system stability or causing denial of service. The flaw is not known to provide code execution, privilege escalation, or information disclosure.

Why it matters to the business

Systems using affected Linux kernels with Wi-Fi functionality may become unstable if the vulnerable scan path is repeatedly triggered, especially on endpoints, embedded devices, appliances, or kiosks that rely on wireless networking. The most likely consequence is degraded availability: increased memory pressure, service disruption, device hangs, or reboots. Current public risk signals are low: EPSS is 0.00112, the issue is not in CISA KEV, is not reported as ransomware-associated, and no exploit maturity is currently reported.

How an attack unfolds

An attacker needs a way to cause the local Linux Wi-Fi stack to initiate scan requests that enter the split 6 GHz scanning path and fail. This is typically a local attack surface exposed through nl80211/netlink interactions used by Wi-Fi management tooling such as wpa_supplicant or equivalent network managers. By repeatedly causing scan failures, the attacker causes the kernel to allocate an internal scan request object and then miss the corresponding free operation. Each failed attempt leaks kernel memory. Over time, accumulated leaks can exhaust available memory or increase memory pressure enough to disrupt normal system operation. There is no indication from the provided information that the issue is remotely exploitable across the network without local ability to interact with the wireless subsystem.

How to fix it

Upgrade to a Linux kernel build that includes the upstream cfg80211 fix for the split 6 GHz scanning leak. Because no specific affected product list or fixed package versions were provided, use vendor kernel advisories for the relevant distribution, appliance, embedded platform, or device firmware and apply the first kernel update that references this CVE or the cfg80211 split 6 GHz scan memory leak fix. Where immediate patching is not possible, reduce exposure by limiting local user access to Wi-Fi management capabilities, restricting untrusted applications from interacting with nl80211/netlink Wi-Fi controls, disabling Wi-Fi on systems that do not require it, or disabling 6 GHz Wi-Fi scanning where operationally acceptable. Rebooting may temporarily clear leaked memory but does not remediate the vulnerability.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release containing the fix, not merely that the package is installed on disk. On Linux, compare uname -r with the fixed kernel package version from the distribution or device vendor. Review vendor changelogs for references to cfg80211, split 6 GHz scanning, rdev->int_scan_req, or this vulnerability. For high-assurance validation, reproduce Wi-Fi scan failure testing in a controlled lab with kernel memory leak detection enabled and confirm that repeated failed scans no longer produce unreferenced cfg80211 scan request objects. Also confirm that systems have been rebooted into the updated kernel after patch installation.

Typical attack path

1. Gain local ability to trigger Wi-Fi scan operations, either directly through nl80211/netlink or indirectly through Wi-Fi management software.
2. Trigger scan requests that exercise split 6 GHz scanning behavior.
3. Force or rely on conditions that cause cfg80211_scan() to fail before normal scan completion cleanup occurs.
4. Repeat failed scan attempts many times, causing rdev->int_scan_req allocations to remain unreleased.
5. Accumulate kernel memory leaks until the device experiences memory pressure, instability, service disruption, or denial of service.

How to detect it

Look for evidence of repeated failed Wi-Fi scan activity followed by kernel memory growth or memory leak reports. Useful sources include kernel logs, dmesg, journald, syslog, NetworkManager logs, wpa_supplicant logs, audit logs for netlink activity where available, and endpoint telemetry showing abnormal scan frequency or memory pressure. If kmemleak is enabled, search for unreferenced objects with backtraces involving cfg80211_scan and nl80211_trigger_scan. Also review timelines for repeated scan failures from wpa_supplicant or network managers followed by out-of-memory events, soft lockups, device reboots, or service restarts. Because this vulnerability causes a memory leak rather than a distinctive payload or dropped file, detection is behavioral and log-based; absence of these indicators does not prove non-exploitation if detailed kernel memory diagnostics were not enabled.

• unreferenced object
• comm "wpa_supplicant"
• kmemleak_alloc
• cfg80211_scan
• nl80211_trigger_scan
• genl_family_rcv_msg_doit
• genl_rcv_msg
• netlink_rcv_skb
• netlink_unicast
• netlink_sendmsg
• rdev->int_scan_req
• split 6 GHz scanning
• Out of memory
• oom-killer
• wpa_supplicant

What your security team should do

• Prioritize patching Linux endpoints, embedded devices, appliances, and mobile/edge systems that use Wi-Fi, especially those permitting local users or applications to initiate wireless scans.
• Inventory systems with 6 GHz-capable Wi-Fi hardware or software support, as they are more likely to exercise the vulnerable code path.
• Monitor kernel and system logs for kmemleak reports, repeated nl80211 scan failures, unusual Wi-Fi scan frequency, and increasing kernel memory pressure.
• Restrict local access to Wi-Fi management interfaces and prevent untrusted users or applications from controlling wireless scanning where possible.
• If patching is delayed, consider disabling Wi-Fi or 6 GHz scanning on systems where wireless connectivity is not required.
• Treat exploitation likelihood as currently low because the issue is not in CISA KEV, has low EPSS, and has no reported public exploit maturity, but still remediate through normal kernel maintenance because availability impact can accumulate over time.