Cloudanix VulnDB

CVE-2026-68404

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in Linux wireless networking code could let someone with access to the computer take full control or crash the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in cfg80211 during NETLINK_URELEASE and NETDEV_GOING_DOWN handling allows a wdev autodisconnect work item to be queued after list removal and RCU grace period, enabling use-after-free or memory corruption in the wireless device teardown path.

Why it matters to the business

Local attackers on affected Linux systems can achieve kernel-level code execution or system crash, risking full host compromise and loss of control over wireless-enabled devices.

How an attack unfolds

An attacker with local access releases a NETLINK_GENERIC socket that owns a connection while simultaneously triggering network device down events; the timing window allows the plain work_struct to execute after the wdev has been removed from the list and RCU synchronized, leading to invalid memory access.

How to fix it

Upgrade to a Linux kernel containing the commit that converts the autodisconnect work to a wiphy_work, adds mutex-protected cancellation after list_del_rcu, and ensures pending work is drained before wdev teardown.

How to confirm the fix worked

Verify the presence of the wiphy_work conversion and post-list_del_rcu cancellation logic in the cfg80211 source; confirm via kernel build logs or runtime testing that NETLINK_URELEASE cannot queue work after synchronize_net completes.

Typical attack path

  1. Gain local unprivileged access on a Linux host with cfg80211 wireless support
  2. Create and release a netlink socket that owns a cfg80211 connection
  3. Trigger NETDEV_GOING_DOWN and NETLINK_URELEASE events in rapid succession
  4. Exploit the window where the work item runs after wdev list removal and synchronize_net

How to detect it

Review kernel logs for cfg80211 or netlink notifier warnings around device unregister events; inspect for unexpected oops or use-after-free traces involving wdev or disconnect_wk after socket release.

What your security team should do

  • Prioritize kernel updates on all wireless-enabled Linux systems within standard patch windows
  • Monitor upstream stable and distribution kernel releases for the referenced cfg80211 fix
  • Restrict local user access on high-value wireless hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities