CVE-2025-38643 in Linux
Summary
by MITRE • 08/22/2025
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()
Callers of wdev_chandef() must hold the wiphy mutex.
But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes:
WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98
[<6003c2b3>] show_stack+0x10e/0x11a
[<6002ec30>] ? _printk+0x0/0x98
[<60037608>] dump_stack_lvl+0x71/0xb8
[<6063717b>] ? wdev_chandef+0x60/0x165
[<6003766d>] dump_stack+0x1e/0x20
[<6005d1b7>] __warn+0x101/0x20f
[<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d
[<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec
[<60751191>] ? __this_cpu_preempt_check+0x0/0x16
[<600b11a2>] ? mark_held_locks+0x5a/0x6e
[<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d
[<60052e53>] ? unblock_signals+0x3a/0xe7
[<60052f2d>] ? um_set_signals+0x2d/0x43
[<60751191>] ? __this_cpu_preempt_check+0x0/0x16
[<607508b2>] ? lock_is_held_type+0x207/0x21f
[<6063717b>] wdev_chandef+0x60/0x165
[<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f
[<60052f00>] ? um_set_signals+0x0/0x43
[<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a
[<6007e460>] process_scheduled_works+0x3bc/0x60e
[<6007d0ec>] ? move_linked_works+0x4d/0x81
[<6007d120>] ? assign_work+0x0/0xaa
[<6007f81f>] worker_thread+0x220/0x2dc
[<600786ef>] ? set_pf_worker+0x0/0x57
[<60087c96>] ? to_kthread+0x0/0x43
[<6008ab3c>] kthread+0x2d3/0x2e2
[<6007f5ff>] ? worker_thread+0x0/0x2dc
[<6006c05b>] ? calculate_sigpending+0x0/0x56
[<6003b37d>] new_thread_handler+0x4a/0x64
irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf
hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf
softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985
softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/28/2026
The vulnerability identified as CVE-2025-38643 resides within the Linux kernel's wireless subsystem, specifically in the cfg80211 component responsible for managing wireless device configuration and channel operations. This issue manifests as a missing lock in the function cfg80211_check_and_end_cac(), which is crucial for handling channel access control and DFS (Dynamic Frequency Selection) operations in wireless networks. The problem stems from an inconsistency in lock acquisition protocols where certain functions that call wdev_chandef() are required to hold the wiphy mutex, yet the worker function cfg80211_propagate_cac_done_wk() does not acquire this necessary lock, leading to potential race conditions and system instability.
The technical flaw occurs when the wireless subsystem processes DFS channel availability checks, particularly during mesh peer connections involving DFS channels. The warning message indicates that wdev_chandef() is being invoked without proper locking, triggering kernel warnings and potentially causing system crashes or unpredictable behavior. This condition violates fundamental concurrency control principles and is classified under CWE-362, which addresses Race Conditions, as the lack of proper synchronization mechanisms allows multiple execution paths to access shared resources simultaneously without adequate protection. The worker function operates in a different context than the callers of wdev_chandef(), creating a scenario where the mutex is not held when required, thus exposing the system to data corruption and memory consistency issues.
The operational impact of this vulnerability extends to wireless network stability and system reliability, particularly in environments using mesh networking or DFS channel operations. When the mesh_peer_connected_dfs test from hostapd is executed, the system becomes vulnerable to kernel panics or memory corruption due to the improper locking mechanism. This could result in complete system crashes, network disconnections, or denial of service conditions affecting wireless connectivity for all users. The vulnerability affects systems running kernel versions where the mac80211 wireless subsystem is active, potentially impacting enterprise wireless infrastructure, consumer devices with wireless capabilities, and embedded systems relying on Linux kernel wireless functionality. The issue demonstrates a failure in the ATT&CK framework's TA0005 - Defense Evasion category, as it represents a kernel-level bypass of expected locking mechanisms that should prevent unauthorized access to shared resources.
Mitigation strategies for this vulnerability involve ensuring that the cfg80211_propagate_cac_done_wk worker function properly acquires the wiphy mutex before invoking wdev_chandef(). This requires modifying the function to include the necessary locking mechanism, typically by adding a call to mutex_lock(&wiphy->mtx) before the wdev_chandef() invocation and mutex_unlock() afterward. System administrators should apply the relevant kernel patches as soon as they become available, particularly those addressing the specific locking behavior in the mac80211 subsystem. Additionally, monitoring systems should be configured to detect kernel warnings related to wdev_chandef and mutex operations, as these may indicate the vulnerability's exploitation or potential system instability. Organizations using wireless mesh networks or DFS-enabled configurations should prioritize patching to prevent the race condition that could lead to complete wireless service disruption or system compromise. The fix should be validated through comprehensive testing using the mesh_peer_connected_dfs test case to ensure proper locking behavior and prevent regression in wireless functionality.