Skip to content
VulniPulse
Advisory severityMedium5.5Vendor: LowRed Hat Linux

Medium [CVE-2026-68408] convert pmsr_free_wk to wiphy_work to fix deadlock

This medium-severity Red Hat Linux advisory covers CVE-2026-68408 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 9.

Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.

CVE-2026-68408 Source published Source updated

VulniPulse record published Record updated

Affected products & platforms
Red Hat LinuxLinux Kernel
Open source advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

Summary

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.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.

Official advisory · medium-confidence parse· fetched 3 days ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.

Official advisory · medium-confidence parse· fetched 3 days ago·verify at source

Mitigation

The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.

Official advisory · medium-confidence parse· fetched 3 days ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.