CVE-2026-68407 Causes Linux Wi-Fi AP Memory Leak

The NVD page for CVE-2026-68407 was unavailable with a 502 Bad Gateway response when checked on August 11, 2026, leaving its CVSS score, affected-version range, and reference list unverified there. The upstream Linux source record is much clearer: the fix is commit

, authored by Zhao Li and committed by Intel wireless maintainer Johannes Berg on July 6, 2026. Linux’s commit message identifies the fault precisely: rejected RNR data had not yet been attached to the beacon configuration, so the error path did not own up to freeing it.

That distinction changes the risk assessment. This is not a flaw triggered by a hostile nearby access point broadcasting a malformed beacon. The bad input reaches the kernel through the local

control interface while software is configuring a Wi‑Fi access point. An attacker would therefore need the ability to submit crafted AP beacon configuration to the affected Linux kernel, rather than merely be within radio range of the machine.

The error is in AP setup, not Wi‑Fi reception​

is the Linux kernel’s userspace-facing interface for wireless configuration. Tools and services such as

use it to create and update access points, configure beacon contents, select channels, and apply 802.11 feature settings. The affected function,

, is run while the kernel parses beacon-related data supplied by userspace for an AP interface.

The affected data structures concern two advanced 802.11 features:

• Multiple BSSID, or MBSSID, lets an access point advertise several logical networks from one transmitting radio and beacon stream.
• Reduced Neighbor Report, or RNR, carries information that helps stations discover neighboring BSSs, particularly in modern multi-band and 6 GHz deployments.
• Enhanced Multiple BSSID Advertisement, usually shortened to EMA, splits non-transmitted BSSID profiles across beacon transmissions instead of placing every profile in each beacon.

The original EMA RNR support requires userspace to provide at least as many RNR entries as MBSSID entries. The kernel checks that relationship after parsing the supplied data. If the RNR count is lower than the MBSSID count, the request is invalid and

returns

.

Before the fix, though, the code returned the error without releasing the heap allocation holding parsed RNR information. The upstream correction is only four changed lines: it wraps the mismatch condition in braces, calls

, then returns the existing

error. The small patch is a reminder that a clean rejection of malformed input is not necessarily clean if ownership of intermediate allocations is unclear.

A 2023 feature created the vulnerable path​

The upstream fix points back to

, a 2023 change titled

. That earlier feature added the nested

attribute and established the relationship between RNR and MBSSID element counts.

The Linux Stable mailing list shows that the RNR-for-EMA support was backported into the 6.1 stable series in January 2026. That is significant because it means the faulty parsing path is not confined to a short-lived development branch or the newest upstream kernel. It can exist in long-supported vendor kernels that have picked up the underlying EMA functionality.

At the same time, administrators should not equate an upstream commit date with a distribution fix date. Linux distributors routinely backport security corrections without changing the visible base kernel version, while some carry wireless feature backports that differ from upstream’s exact history. A system reporting an older-looking

can be patched; conversely, an appliance on a newer base may still be exposed if its vendor has not taken this particular change.

The available record does not yet provide a reliable distribution-by-distribution answer. NVD’s failure on August 11 means it could not be used to confirm a formal affected-version range, and no public Red Hat, Ubuntu, SUSE, Debian, or Android security bulletin for CVE-2026-68407 was located at publication time. That omission is the operational problem here: the source fix exists, but fleet managers cannot responsibly treat “new enough kernel” as a complete answer until their kernel vendor maps the CVE to shipped packages.

The practical impact is denial of service through repeated bad configuration​

The bug is a memory leak, not an out-of-bounds write, use-after-free, authentication bypass, or direct privilege-escalation primitive. Each malformed AP configuration attempt that reaches this error path leaves an RNR allocation behind. Repetition can consume kernel memory and degrade or destabilize the host, making local or delegated administrative control over AP configuration the meaningful threat boundary.

That places the most relevant systems in a narrower category than laptops connecting to ordinary Wi‑Fi networks:

• Linux routers, access points, and appliances using hostapd with MBSSID and EMA capabilities merit prompt vendor review.
• Enterprise Linux systems where a privileged service, container, orchestration platform, or tenant can create AP interfaces or send raw wireless configuration requests deserve access-control review.
• Wireless testing rigs using mac80211_hwsim, virtual radios, or custom automation may be able to reproduce the faulty path even without a physical radio transmitting an AP beacon.
• General Linux desktops and servers that never operate Wi‑Fi in AP mode have little practical exposure, even if the vulnerable code is present.

The scope is constrained further by the feature itself. The triggering condition depends on a supplied EMA RNR list being shorter than the supplied MBSSID list. A standard Wi‑Fi client connection does not create those inputs, and a remote attacker cannot reach this code simply by advertising a malformed RNR or MBSSID element over the air.

No public exploitation report was located before publication. That absence is not proof that the flaw cannot be abused, but the code path and the patch both support classifying it as a configuration-plane resource-exhaustion bug, rather than treating it as a nearby-radio compromise of every Linux wireless device.

Why ordinary WSL 2 is outside the usual exposure path​

Microsoft documents that WSL 2 uses virtualized networking, normally through NAT, with its own virtual Ethernet adapter and IP address. That arrangement gives a Linux distribution network connectivity; it does not hand the guest direct control of Windows’ physical Wi‑Fi adapter through the Linux

stack.

As a result, a Windows 10 or Windows 11 machine running a conventional WSL 2 distribution does not become exposed to CVE-2026-68407 merely because it has WSL installed, uses Wi‑Fi, or runs Linux networking tools. The host’s physical WLAN device continues to be operated by the Windows driver stack, and the WSL guest sees virtual networking rather than an AP-capable Linux wireless interface.

The exceptions are deliberate hardware and kernel changes. Microsoft supports attaching USB devices to WSL 2 through USB/IP tooling; while its documentation uses development peripherals as examples, forwarding a compatible USB Wi‑Fi adapter into a Linux guest can create a different hardware boundary. A custom WSL kernel, direct USB adapter assignment, or a full Linux virtual machine configured to manage an adapter in AP mode should be evaluated like a conventional Linux wireless deployment.

For Windows administrators, the immediate check is therefore simple: identify WSL instances or Linux VMs that have been given direct access to Wi‑Fi hardware and run AP-capable tooling. If there are none, this CVE does not require a Windows update or a change to the system’s normal wireless connection.

Patch by vendor package, not by guesswork​

Linux administrators should first determine whether their access points use MBSSID/EMA features and whether the deployed kernel includes the RNR-for-EMA support introduced by the 2023 upstream commit. The upstream repair is identifiable as

; vendor advisories may reference that full hash, its short form

, or only CVE-2026-68407.

Until a vendor publishes package mappings, the sensible mitigation is to prevent untrusted users and workloads from controlling AP configuration, particularly raw

operations and

configuration inputs. Disabling EMA/MBSSID features where they are not required also removes the vulnerable configuration path, though updating to a vendor-supplied kernel remains the correct permanent fix.

The immediate consequence is narrow but actionable: Linux wireless AP operators should track CVE-2026-68407 through their distribution’s kernel advisory process, while ordinary Windows and standard WSL 2 users can treat it as a Linux AP-stack maintenance issue rather than a flaw in Windows Wi‑Fi.