CVE-2025-38290

What it actually does

In ath12k WLAN recovery, ath12k_core_halt only reinitializes the arvifs list head, leaving subsequent nodes with stale prev pointers; this causes list_del to fail with __list_del_entry_valid_or_report panic when ath12k_mac_vdev_delete runs concurrently before the data_lock.

Why it matters to the business

Systems using affected ath12k WiFi hardware experience unrecoverable kernel panics during normal wireless interface removal or recovery, resulting in unplanned downtime, loss of network connectivity, and possible corruption of in-flight operations.

How an attack unfolds

An attacker with local or adjacent access triggers WLAN recovery while a vif removal is in progress; the race leaves an invalid list node that list_del later detects, forcing a kernel panic and denial of service.

How to fix it

Update linux-lts (Alpaquita 23) to 6.1.56-r0 or later, linux-lts (stream) to 6.6.58-r0 or later, or apply commit be049199dec9189602bc06e2c70eda3aa0f2ea6e in the stable kernel tree; rebuild and reboot with the corrected ath12k driver.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking ath12k_core_halt reinitializes every arvifs node; reproduce the original race condition in a test environment and verify no panic occurs.

Typical attack path

1. Trigger ath12k_core_halt during active vif operations
2. Initiate vif removal before spin_lock_bh on data_lock
3. Execute list_del on the now-corrupted arvifs node
4. Induce kernel panic via __list_del_entry_valid_or_report

How to detect it

Search kernel logs and crash dumps for the call trace containing __list_del_entry_valid_or_report followed by ath12k_mac_remove_link_interface and ath12k_scan_vdev_clean_work; correlate with ath12k module load times around the panic.

What your security team should do

• Prioritize kernel package upgrades on all ath12k-equipped hosts within the next maintenance window
• Add kernel panic monitoring for ath12k call traces to existing alerting
• Test the updated driver under concurrent recovery and vif-delete workloads before broad deployment