Look up another CVE · open CVE-2025-21729 in the interactive tracker

CVE-2025-21729

wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion

7.8 EPSS 0.2% AV:L

Published 2025-02-27 (20 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2025-21729 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	fixed	6.12.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.12.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.12.13-1	Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/wireless/realtek/rtw89/mac80211.c

What this is: REALTEK WIRELESS DRIVER (rtw89)MAINTAINERS section matched on drivers/net/wireless/realtek/rtw89/ · linux-wireless@vger.kernel.org · Maintained
Kernel module: rtw89_core

Check it on the machine

grep -wE 'CONFIG_RTW89|CONFIG_RTW89_CORE|CONFIG_WLAN|CONFIG_WLAN_VENDOR_REALTEK' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w rtw89_core

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, s390x/s390x
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_RTW89, CONFIG_RTW89_CORE, CONFIG_WLAN, CONFIG_WLAN_VENDOR_REALTEK
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2025-02-27 (20 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.20%, higher than 9.5% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.18	6.12.13	2403cb3c235d
5.18	6.13.2	5afcd6fcd1e1
5.18	6.14	ba4bb0402c60

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The vulnerable path is `ieee80211_ops::cancel_hw_scan`, reached only through local wireless-stack operations (nl80211 TRIGGER_SCAN plus a connect/auth that triggers `ieee80211_scan_cancel`); no attacker-supplied frame is parsed on this path. An adjacent attacker can only indirectly nudge the local supplicant into scan/reconnect cycles, so delivery is local.
AC:LAttack complexity, low: The attacker drives both sides of the race — it starts the hardware scan and issues the connect that invokes cancel_hw_scan — and the window is wide because the cancel thread blocks on `rtwdev->mutex` for the entire duration of the firmware-driven completion work. The sequence can be repeated indefinitely until the race is won.
PR:LPrivileges required, low: Only the ability to request scans and connections is needed; on typical desktop and mobile deployments an ordinary logged-in user can drive both through NetworkManager/wpa_supplicant (polkit/Settings), and the underlying nl80211 gate is the namespaced `GENL_UNS_ADMIN_PERM` capability rather than real root.
UI:NUser interaction, none: No victim action is needed — the attacker issues the scan and connect requests itself, and the crash trace shows the trigger arriving from the automatic `cfg80211_conn_work` SME reconnect path.
S:UScope, unchanged: The corruption and the crash are confined to the kernel's own memory and the rtw89 driver state; no VM, IOMMU, or sandbox boundary is crossed.
C:HConfidentiality impact, high: `rtwvif->scan_req`/`scan_ies` dangle into the kfree'd, heap-sprayable `local->hw_scan_req`, and the driver dereferences pointers read out of it (`req->channels[idx]`, `req->ies`), giving an attacker-groomable read primitive that can disclose kernel memory.
I:HIntegrity impact, high: The use-after-free on `local->hw_scan_req` lets an attacker reclaim the freed allocation and control the fields the driver uses to build firmware H2C commands and channel lists, which is exploitable for memory corruption and control-flow influence.
A:HAvailability impact, high: The documented outcome is a kernel oops (`null-ptr-deref` on `req->no_cck`) inside a workqueue while `rtwdev->mutex` and the wiphy mutex are held, killing the worker with locks held and leaving the wireless device — and potentially the system — hung.