CVE-2026-68404: Linux Wi-Fi Race Fixed in 7.2-rc4

The National Vulnerability Database added the record on August 10, 2026, using kernel.org as its source. Its description tracks an upstream cfg80211 change titled “wifi: cfg80211: use wiphy work for socket owner autodisconnect.” Kernel wireless maintainer code shows the change was included in a July 2026 wireless pull request alongside a broader set of Wi-Fi robustness fixes.

The significant detail is the race, not the automatic disconnect feature itself. Linux’s

interface lets user-space networking software control Wi-Fi functions through Generic Netlink sockets. When the socket that owns a connection or connection attempt closes, cfg80211 schedules work to clean up that connection. Before this fix, that queued cleanup used an ordinary

, which had a teardown gap when an interface was simultaneously going down or being removed.

The teardown path had two independent clocks​

The vulnerable sequence requires more than merely disconnecting from Wi-Fi. A

notification must observe a socket-owned connection and queue

, while the network device is being dismantled through the

and cfg80211 unregister paths.

The former teardown path cancelled the regular work item before unregistering the wireless device. But, as the kernel.org description explains, a Netlink-release notifier that had already seen the owner’s Netlink port ID could enqueue the work after that cancellation returned. The wireless device could then be removed from cfg80211’s device list, and the networking stack could finish its RCU synchronization without necessarily draining the newly queued worker.

In practical terms, one CPU could conclude that the pending auto-disconnect work had been cancelled while another path was still capable of adding it back. The problem is a lifetime and ordering failure: cleanup associated with a wireless device can outlive the teardown point that was supposed to make the device unreachable.

The CVE description does not claim a confirmed remote-code-execution, privilege-escalation, or denial-of-service exploit. It also does not assign a CWE category, CVSS 3.x score, or CVSS 4.0 score. NVD’s enrichment fields remain unassessed as of August 11, 2026. That absence is material: this is a real kernel correctness fix with a CVE identifier, but the public record does not yet establish an attacker model, exploitability rating, or demonstrated impact beyond the race condition corrected upstream.

wiphy_work makes teardown and cleanup share the same lock​

The upstream fix changes

from a generic Linux workqueue object to

, cfg80211’s work mechanism associated with a physical wireless device, or wiphy. The callback already needed the wiphy mutex;

runs under that mutex by design.

That locking change is the core repair. It allows cfg80211 to cancel pending auto-disconnect work while holding the same mutex that governs the worker, avoiding the locking problem that would come from trying to use a synchronous generic-work cancellation against a worker that itself takes the wiphy lock.

The patch also moves a cancellation step to after

and

during wireless-device unregistration. That order closes the remaining window:

• A Netlink socket-release notifier that already reached the wireless-device list may queue the work, but the unregister path cancels it after the list removal and synchronization point.
• A notifier that has not already found the wireless device cannot locate it after the RCU-protected list removal has completed.

The patch changes more than the disconnect task. It also converts

, used around peer measurement handling, to

. That accompanying conversion appears to be needed because the relevant initialization and teardown logic now works through the same cfg80211 work model, but CVE-2026-68404 specifically concerns socket-owner auto-disconnect.

This is a useful distinction for incident response. The code change may be broader than the CVE’s one-sentence label, yet the reported vulnerability is narrowly tied to the interaction among

, socket ownership, queued disconnect work, and interface teardown.

The affected-version record is useful, but incomplete for package management​

NVD’s affected-version data says the issue exists in Linux kernel code beginning with version 4.11. It identifies Linux 7.2-rc4 as the upstream version containing the original fix and marks Linux 7.1.6, along with the 7.1 maintenance line indicated in the record, as unaffected. The record also lists two stable Git commits:

and

.

There is an operational catch: neither NVD nor the CVE record maps those two stable commit IDs to named distribution package versions. Administrators cannot safely conclude that a kernel is fixed merely because its visible version looks older than 7.2-rc4; Linux distributors routinely backport fixes without changing the upstream base-version portion of their package names.

Conversely, a kernel reported as a long-term-supported version may still be exposed if its vendor has not yet imported one of the stable backports. The right check is the installed kernel package changelog, vendor advisory, or source tree—not an upstream version comparison alone.

For systems built from a self-maintained tree, the relevant verification point is whether the source contains the

conversion for

and the post-

call in cfg80211 unregistration. For packaged systems, use the vendor’s CVE tracker once vendors publish assessments. As of August 11, no Red Hat, Ubuntu, SUSE, Debian, or Microsoft distribution-specific advisory surfaced in the public reporting reviewed for this CVE.

This is not a native Windows Wi-Fi bug​

CVE-2026-68404 affects Linux kernel files including

,

, and

. It does not apply to the native Wi-Fi stacks in Windows 10 or Windows 11, nor does it imply a patch requirement for Windows wireless drivers, Windows Update, or Microsoft’s WLAN AutoConfig service.

Windows administrators should care where Windows hosts Linux workloads. The relevant inventory includes Linux virtual machines with direct use of a wireless adapter, Linux laptops and embedded devices, wireless routers or appliances built on a Linux kernel, and custom kernels that expose cfg80211-managed wireless hardware. A normal WSL 2 installation typically uses virtualized networking rather than giving the Linux guest direct control of the host’s physical Wi-Fi adapter, so merely having WSL installed does not establish exposure.

The public advisory does not specify whether ordinary unprivileged local users can create the required socket-owned connection state, whether a malicious process can reliably trigger the race, or whether a particular Wi-Fi driver is necessary. That makes broad emergency remediation based on a speculative exploitation scenario unjustified. It does make ordinary kernel maintenance important for devices whose Wi-Fi is managed through cfg80211.

Patch the kernel, then verify the real delivery path​

The upstream change was already part of the wireless subsystem’s July pull activity before NVD published the CVE on August 10. The CVE’s appearance should therefore be read as security tracking catching up with an upstream lifetime fix, not as evidence that a newly discovered attack is actively circulating.

For fleet operators, the immediate work is straightforward:

• Confirm whether deployed kernels are Linux 7.1.6 or a later fixed vendor build, or whether their vendor has backported either of the stable fixes named in the CVE record.
• Prioritize systems that directly manage Wi-Fi interfaces through NetworkManager, wpa_supplicant, iwd, custom nl80211 clients, or embedded wireless-management software.
• Reboot after installing a fixed kernel, because the vulnerable cfg80211 code remains resident until the new kernel is running.
• Avoid assigning a severity score internally from the CVE number alone while NVD has no vector, no CWE, and no published exploitability analysis.

The unresolved issue is package-level visibility. Upstream has provided the code correction and NVD has identified the affected lineage, but the public record still does not say which supported enterprise and consumer distribution kernels contain the two stable backports. Until vendors publish that mapping, kernel package changelogs—not the headline version alone—are the decisive evidence.