CVE-2026-68408

wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock

N/A
Published: August 10, 2026 at 12:04 PM UTC
Updated: October 21, 2026 at 01:19 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

28d3551f8d8cb3aec7497894d94150fe84d20e5e37e776e2e0a523731e2470dce6d563f0e8632a406.1.1676.12.786.18.206.19.106.6.1306dccbc9f3e1d38565dff7730d2b7d1e8b16c9b097.072b7ea786b8e570ae11149e9089859a4a8634a13a1b7a843f12a0c3e9d3a2ca607ce451916ef42cfd32c07ef1880fe20cf4ab223dbfedc9c0b2816aa
Vendor states this is fixed in 0a77d9fb4d5c0e01306cd406ffdee8f1fe955c0e (fixed)
Vendor states this is fixed in 133684982dd0c24359fcc641d19d89cc17d6e5ef (fixed)
Vendor states this is fixed in 21512b5f7a74fd18c996c22e6854efe57d570816 (fixed)
Vendor states this is fixed in 2b0eab425e1f658d8fe1df7590e3b9af5959505e (fixed)
Vendor states this is fixed in 6.12.101 (unaffected)
Vendor states this is fixed in 6.18.42 (unaffected)
Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.20, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.6.160 (unaffected)
Affected range stops below 6.7, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 7.0 (unaffected)
Vendor states this is fixed in 7.1.6 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card