CVE-2026-68406: Patch Linux Wi-Fi FTM Validation Gap

The National Vulnerability Database published the record on August 10, 2026, based on the Linux kernel CVE team’s entry. Its description is terse, but the underlying patch and the affected-file record identify the problem precisely: it is in

and the cfg80211 Peer Measurement Service, or PMSR, request path. The bug is not a flaw in ordinary Wi‑Fi packet reception, WPA authentication, or an access point’s handling of traffic from nearby devices.

That difference substantially limits the practical exposure. The vulnerable path processes a specially constructed

netlink request from local user space, and it only proceeds where the wireless device exposes PMSR capability support. The CVE record says Linux kernels from version 5.0 onward are affected unless a downstream vendor has backported the correction.

The bug is an unchecked value used as a bitmap shift​

Fine Timing Measurement, or FTM, is an IEEE 802.11 ranging feature. It can be used to estimate distance between Wi‑Fi devices and access points, supporting positioning and location-oriented functions. Linux represents an FTM request’s frame preamble with the

enumeration, whose valid values are the five defined preambles: legacy, HT, VHT, DMG, and HE.

Before the fix, the PMSR parser accepted the preamble field as a 32-bit netlink value. It then tested whether the Wi‑Fi device advertised support for the selected preamble by evaluating a bitmap with the supplied value as the bit number. A normal capability check therefore became unsafe input handling: instead of first confirming that the value referred to one of the five defined preambles, the kernel could use an arbitrary out-of-range integer in the shift operation.

This is why the patch is more meaningful than its compact commit subject suggests. The new policy rejects values outside the defined

range before the bitmap operation. It also removes a check made unnecessary once the policy owns validation. The correction is a clean example of placing validation at the netlink boundary rather than asking each later parser stage to defend itself against malformed attributes.

The record does not say that arbitrary memory can be read or written, that code execution is possible, or that the flaw has been exploited. NVD has not assigned CVSS 4.0, CVSS 3.x, or CVSS 2.0 metrics, and it has not assigned a CWE. Treating an unchecked bit shift as proof of a remotely exploitable kernel takeover would go beyond the evidence presently published.

The affected code is not reachable on every Wi‑Fi adapter​

The most important operational detail is buried in the implementation rather than the CVE headline. PMSR request handling first checks whether the registered wireless device has

capabilities. If it does not, the request is rejected as unsupported. The FTM parser then validates the requested channel bandwidth and compares the requested preamble to the adapter’s advertised FTM preamble bitmap.

In other words, a system is not exposed merely because it runs an affected Linux version and has a wireless interface. The relevant radio driver and hardware must implement and advertise peer-measurement support, and a local process must be able to submit the malformed

request through the wireless netlink interface.

That is still a meaningful concern for managed Linux endpoints and embedded equipment. A desktop fleet may include Intel, Qualcomm, or other radios with varying support across driver and firmware generations; appliances can expose different capabilities from the same nominal kernel series. Security teams should avoid reducing this case to a kernel-version-only spreadsheet exercise. Kernel version establishes whether the bad code is present, while device capability establishes whether the vulnerable parser is usable.

The Linux kernel project itself cautions that its CVE assignments are deliberately broad because it cannot know which portions of the kernel are enabled or reachable in a particular deployment. CVE-2026-68406 illustrates that policy well. The assigned CVE is useful for tracking the fix, but it does not establish a universal exploit path across every distribution, device, or Wi‑Fi chipset.

Stable fixes landed across five maintained lines​

The CVE record lists five stable-tree fixes, covering the maintained series that received the patch. Administrators running an upstream-like kernel can use the following versions as clear fixed thresholds:

• Linux 6.6 is fixed at 6.6.148 and later.
• Linux 6.12 is fixed at 6.12.101 and later.
• Linux 6.18 is fixed at 6.18.42 and later.
• Linux 7.1 is fixed at 7.1.6 and later.
• Linux 7.2 includes the correction from release candidate 7.2-rc4 onward.

The record also identifies the mainline fix lineage as resolved in 7.2-rc4. That does not mean every affected installation must move to a release candidate. It means the mainline correction was accepted there while stable maintainers applied equivalent backports to older supported branches.

The practical trap is that enterprise distribution version strings do not necessarily match those upstream thresholds. Red Hat Enterprise Linux, Ubuntu, Debian, SUSE, Android-derived kernels, appliance vendors, and cloud images frequently backport targeted security patches while retaining an older base version. Conversely, a custom kernel may retain an old vulnerable commit even if its local version label appears modern.

For that reason, a scan that labels every

kernel below 6.6.148 as vulnerable will produce false positives where a distributor has already backported the specific patch. It will also miss bespoke builds that report an appealing version string but exclude stable fixes. The package advisory and changelog from the operating system or appliance vendor remain the authoritative answer for a supported deployment.

Windows systems are not directly affected, but WSL2 deserves inventory​

A standard Windows 10 or Windows 11 installation does not run

,

, or the Linux wireless stack named in CVE-2026-68406. There is no Windows Update action associated with this CVE.

Windows Subsystem for Linux 2 is different in architecture: Microsoft documents that WSL2 runs a Linux kernel inside a lightweight utility virtual machine. For organizations that inventory WSL2 as part of endpoint security management, the kernel version should be recorded alongside conventional Linux hosts. PowerShell’s

reports the WSL kernel version, and

is Microsoft’s supported update path.

But WSL2 should not be classified as exposed simply because it uses Linux. The vulnerable parser requires a guest-visible Wi‑Fi device that advertises PMSR capability. Having an Ubuntu, Debian, or Kali distribution installed under WSL2 does not by itself demonstrate that condition. A managed WSL2 environment with unusual networking, USB device passthrough, or custom kernels warrants a closer check; normal WSL2 inventory is the sensible first step.

What administrators should do now​

Start with the running kernel rather than a distribution’s marketing release number:

If the host is on an upstream-style stable branch, compare it with the fixed thresholds above and update through the distribution’s normal kernel package channel. Reboot into the new kernel where required; installing the package alone does not remove a flaw from the currently running kernel.

For appliances, wireless controllers, and custom images, confirm whether the vendor incorporated the Linux stable patch for CVE-2026-68406 or the corresponding cfg80211 PMSR preamble validation change. Where the platform exposes Wi‑Fi ranging or location features, prioritize that confirmation over generic “wireless enabled” inventory.

There is no published temporary configuration switch in the CVE record, no CVSS rating, and no documented exploitation. The evidence supports a routine but real kernel hygiene decision: patch systems that run a relevant Linux kernel, give extra attention to PMSR-capable Wi‑Fi hardware, and do not turn an unscored input-validation repair into a claim of broad remote compromise.