CVE-2026-68408
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux WiFi software can cause the whole system to freeze when certain network cleanup tasks happen at the same time.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
A deadlock occurs in the cfg80211 wireless subsystem when a PMSR session is aborted concurrently with interface teardown under wiphy_lock, because cancel_work_sync on a plain work_struct blocks while the work function attempts to acquire the same lock.
Why it matters to the business
Linux systems with WiFi may experience kernel deadlocks causing system hangs, requiring reboots and disrupting wireless network availability and connected services.
How an attack unfolds
An attacker with local access triggers concurrent netlink socket closure for a PMSR session and interface teardown via cfg80211_leave_locked or NETDEV_GOING_DOWN, forcing the work item and wdev_down paths to contend on wiphy_lock.
How to fix it
Upgrade the Linux kernel to a version containing the conversion of pmsr_free_wk to wiphy_work, removal of the explicit guard(wiphy) in the work function, and elimination of cancel_work_sync calls for this work item from the NETDEV_GOING_DOWN handler.
How to confirm the fix worked
Inspect kernel source for the wiphy_work conversion and wiphy_work_cancel usage inside cfg80211_pmsr_wdev_down; confirm the deadlock pattern is absent and test concurrent PMSR abort plus interface down sequences.
Typical attack path
- Obtain local access on a Linux system with cfg80211 wireless support
- Create a PMSR session via netlink
- Close the owning netlink socket while triggering interface teardown
- Induce the race that leads to deadlock under wiphy_lock
How to detect it
Search kernel logs for hung task warnings or deadlock reports involving cfg80211_pmsr_process_abort or wiphy_lock during interface teardown; examine dmesg and syslog for NETDEV_GOING_DOWN events coinciding with PMSR work items.
What your security team should do
- Prioritize kernel updates on all WiFi-enabled Linux systems
- Review wireless configuration and netlink usage for exposure to PMSR sessions
- Monitor system stability during interface state changes
The record
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|