[SRU][J][PATCH 0/1] CVE-2025-38643

[Cengiz Can]

https://ubuntu.com/security/CVE-2025-38643

[ Impact ]

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

[ Fix ]

jammy/linux: backported from 2c5dee15239f

The fix makes cfg80211_check_and_end_cac() acquire the wiphy mutex around
the call path that reaches wdev_chandef() via
regulatory_propagate_dfs_state(), satisfying the locking contract that
callers of wdev_chandef() must hold the wiphy mutex.

This tree lacks the guard(wiphy) scope-based lock helper, so the backport
replaces guard(wiphy)(&rdev->wiphy) with an explicit wiphy_lock() at
function entry and wiphy_unlock() before the single return. It also omits
the unused link_id, since this tree's loop uses wdev->chandef directly with
no per-link iteration.

[ Test Plan ]

Build and boot tested.

[ Where Problems Could Occur ]

A regression would most likely surface in Wi-Fi setups that use DFS radar
channels, such as access point, mesh, or IBSS configurations that run
channel availability check (CAC) on the 5 GHz band across multiple radios
sharing regulatory state. A mistake in the added locking could, in the
worst case, cause a deadlock or lockdep splat in the cfg80211 CAC
propagation path. Systems without Wi-Fi hardware, and Wi-Fi users who never
operate on DFS channels, are not affected by this change.

[ Other Info ]

Kybele flow-v11-25-ga27c0fa6. Reference: 5705a2fe/v1