CVE-2026-68408: Linux Wi-Fi PMSR Teardown Deadlock Fix

The important detail is that this is a follow-on regression. Linux had already added a synchronous cancellation step for

earlier in 2026 to stop an asynchronous Peer Measurement Service Request, or PMSR, abort from reaching a driver after its wireless interface had been torn down. That earlier correction addressed a plausible crash or use-after-free-style teardown hazard. The newly assigned CVE covers the locking deadlock introduced by waiting synchronously for that work while the caller already holds the wireless device’s

.

In practical terms, the kernel exchanged one teardown failure mode for another: instead of permitting a queued abort callback to outlive the interface, a narrow concurrent sequence could leave two kernel contexts permanently waiting on one another.

The deadlock sits in Wi‑Fi ranging cleanup​

PMSR is not ordinary association, scanning, or packet transmission logic. It provides the cfg80211 interface used for peer measurements, including Fine Timing Measurement-style ranging functions. A userspace client issues the request through

, Linux’s netlink control interface for Wi‑Fi; the kernel and driver then manage the measurement and any required abort operation.

The problematic sequence starts when the netlink socket that owns a PMSR request closes.

clears the request owner’s netlink port ID and queues

, an asynchronous worker that eventually calls the PMSR abort path.

At nearly the same time, an interface can be brought down, unregistered, or otherwise torn down. During that cleanup,

runs with

held and calls

to make sure the asynchronous abort worker has stopped before the interface disappears. That is normally a sensible rule: do not let deferred work touch a device that is already gone.

The problem is that the worker also tries to take

before it runs the abort operation. The teardown path holds that lock while waiting for the worker to finish; the worker cannot finish because it is blocked on the lock held by the teardown path. The result is a classic circular wait:

• Interface teardown holds wiphy_lock and waits in cancel_work_sync().
• The queued PMSR cleanup worker waits to acquire wiphy_lock.
• Neither path can progress until the other does.

The same pattern can arise through

, which tears down wireless interfaces under the same lock. This is an availability failure, not evidence of remote code execution or privilege escalation. NVD has not assigned a CVSS score, vector, or CWE category as of August 11, so there is no official severity rating to translate into a conventional patch-priority label.

The patch changes the scheduling model instead of adding another lock​

The kernel fix does more than shuffle the order of two calls. It converts

from a conventional

into a

, cfg80211’s device-aware work abstraction.

That distinction solves the precise failure the previous patch created. A

item is dispatched in a way that is coordinated with

; its callback no longer has to acquire that lock explicitly. More importantly,

can safely be called while the lock is held because the lock itself prevents the work from executing concurrently. It does not need to block waiting for a worker that is itself trying to obtain the same lock.

The patch therefore removes the explicit lock guard from the PMSR free-worker function, changes scheduling to the

mechanism, and replaces the blocking cancellation behavior in the teardown path. It also removes a redundant

call from the

handling path. The upstream explanation is specific:

already performs the required cancellation through

while holding the appropriate lock.

This is the meaningful finding behind the terse CVE title. CVE-2026-68408 corrects a deadlock introduced by the prior protective fix, rather than exposing a long-standing generic flaw in all Linux Wi‑Fi use.

The affected range is narrower than “all Linux Wi‑Fi”​

The NVD record associates the issue with

,

,

, and

. It lists upstream and stable-tree commit ranges, including affected releases from Linux 6.12.78 up to, but not including, 6.12.101, and Linux 6.18.20 up to, but not including, 6.18.42.

It also lists later portions of the 6.1, 6.6, 6.19, and 7.0 lines, which is a clue to how this CVE should be assessed. The vulnerable condition depends on the earlier synchronous-cancellation change being present. A kernel old enough to predate that change may have the earlier teardown-safety bug but does not necessarily contain this exact deadlock. Conversely, comparing only a base version number can be misleading because enterprise distributions commonly backport kernel fixes while keeping a vendor-specific release string.

The March stable backports of the earlier PMSR cancellation change appeared in multiple supported branches, including 6.1, 6.6, 6.12, and 6.18. That explains why the CVE’s affected entries begin at particular point releases rather than at the beginning of each branch. Administrators should treat the NVD ranges as upstream lineage markers, then verify their distribution’s own kernel advisory and changelog.

A kernel reporting

or later within the 6.12 branch, or

or later within the 6.18 branch, is outside the affected range recorded by NVD. For vendor kernels carrying custom version suffixes, the decisive evidence is whether the vendor has incorporated the

conversion patch, not whether the visible version string happens to look newer than an upstream release.

Reachability requires an unusual but real concurrency path​

This is not a bug that normal web browsing, ordinary Wi‑Fi roaming, or simply turning Wi‑Fi off is known to trigger. The affected sequence requires a PMSR session owned through an

socket, closure of that socket, and concurrent wireless-interface teardown while the deferred abort work is pending or running.

That makes the exposure materially narrower than a defect in baseline connection handling. It is most relevant to systems using Wi‑Fi measurement or ranging features, custom wireless-control software, device-validation environments, and platforms whose drivers expose PMSR operations. The Linux wireless stack is shared by many drivers, however, so the code is not restricted to a single Wi‑Fi chipset brand.

A deadlock at this layer can be operationally significant even without a memory-corruption primitive. Depending on the code path and driver behavior, it can leave an interface teardown blocked, complicate device removal or network namespace cleanup, and force recovery actions ranging from resetting the wireless interface to rebooting a system that cannot clear the stuck kernel work.

There is no public indication in the CVE record of exploitation in the wild, and neither NVD nor the kernel material assigns an attack vector or impact score. That absence should not be read as a clean bill of health; it means the record is newly published and has not received NVD’s scoring enrichment. It also means administrators should not inflate a synchronization flaw into a remotely exploitable Wi‑Fi takeover without evidence.

What Windows and Linux administrators should do​

Windows 10 and Windows 11 hosts do not use Linux

for their native wireless adapters, so patching Windows, updating an Intel, Qualcomm, Realtek, or MediaTek Windows driver, or changing Windows Wi‑Fi settings will not address CVE-2026-68408. Microsoft’s WSL 2 environment does run a Linux kernel, but its typical networking arrangement does not hand the physical Wi‑Fi adapter’s cfg80211 control plane to the WSL guest. The CVE becomes relevant to a Windows estate when it includes Linux guests, Linux-based network appliances, bare-metal Linux endpoints, or specialized hardware passthrough configurations using the affected stack.

Administrators responsible for Linux should take three concrete steps:

• Update supported Linux kernel packages through the distribution’s normal security channel, giving priority to systems that use wireless ranging, automated Wi‑Fi test tooling, or device lifecycle operations under load.
• Check the running kernel with uname -r, then inspect the distribution’s kernel changelog or security tracker for CVE-2026-68408 or the cfg80211 PMSR wiphy_work fix. Do not assume an enterprise kernel is vulnerable or fixed solely from its upstream-style version number.
• Avoid attempting a local source-only patch unless the system is already maintained as a custom kernel build. The change spans cfg80211 declarations, core scheduling calls, and PMSR cleanup semantics; selectively removing cancel_work_sync() without adopting wiphy_work would reintroduce the earlier race that allowed abort work to outlive interface teardown.

The immediate operational consequence is straightforward: systems running the affected kernel revisions should move to a vendor kernel containing the conversion patch, especially where PMSR is enabled or exercised. The more revealing lesson is that the March teardown-safety fix and this August deadlock fix form a pair; deploying only the first changes a possible post-teardown callback into a possible permanent lockup.