Look up another CVE · open CVE-2026-90408 in the interactive tracker
CVE-2026-90408
wifi: ath12k: fix overreads in ath12k_wmi_process_csa_switch_count_event()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90408 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath12k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath12k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.
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/ath/ath12k/wmi.c
- What this is
- QUALCOMM ATH12K WIRELESS DRIVERMAINTAINERS section matched on drivers/net/wireless/ath/ath12k/ · linux-wireless@vger.kernel.org · Supported
- Kernel module
- ath12k
Check it on the machine
grep -wE 'CONFIG_ATH12K|CONFIG_WLAN|CONFIG_WLAN_VENDOR_ATH' /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 ath12kPrints 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. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- 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
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_ATH12K, CONFIG_WLAN, CONFIG_WLAN_VENDOR_ATH
- 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
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.7 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.19%, higher than 7.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.3 | 6.18.57 | 23bed4ef132c |
| 6.3 | 7.2.6 | bf97c9d51238 |
| 6.3 | 7.3 | 878654eb78c6 |
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
- Firmware supplies the malformed bytes in WMI_PDEV_CSA_SWITCH_COUNT_STATUS_EVENTID (num_vdevs and the WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT TLV length) on CE2 → ath12k_ce_recv_process_cb → ath12k_htc_rx_completion_handler → ath12k_wmi_op_rx; 802.11 CSA IEs do not carry those fields, so this is the host-firmware HTC path, not an over-the-air frame parse.
- AC:LAttack complexity, low
- Pre-fix ath12k_wmi_tlv_policies had no min_len for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, and ath12k_wmi_process_csa_switch_count_event() used firmware le32 num_vdevs as the vdev_ids[] loop bound with no TLV-length check, so a short event TLV or oversized num_vdevs overreads on every such event with no race.
- PR:NPrivileges required, none
- ath12k_wmi_op_rx() dispatches WMI_PDEV_CSA_SWITCH_COUNT_STATUS_EVENTID from the WMI HTC endpoint (ath12k_connect_pdev_htc_service) with no host uid, capability, or authentication check; the Wi-Fi firmware is the sole source of the event.
- UI:NUser interaction, none
- ath12k_wmi_process_csa_switch_count_event() reads vdev_ids[i] in the num_vdevs loop before the conf->csa_active continue, so a crafted CSA-count WMI event overreads even when the victim never started a channel switch; no mount or other user action is required.
- S:UScope, unchanged
- The vdev_ids[] overread and any oops remain inside the host kernel ath12k/mac80211 authority; the bug does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- Firmware-chosen num_vdevs is an unbounded u32 loop over the WMI_TAG_ARRAY_UINT32 vdev_ids payload (policy min_len 0), so the handler can read far past the CE WMI skb (~2KB); unknown vdev_ids[i] values are also printed by ath12k_warn(), which is an unbounded kernel overread, not a few bytes.
- I:NIntegrity impact, none
- The loop only loads vdev_ids[i] and looks them up with ath12k_mac_get_arvif_by_vdev_id(); it does not write out of bounds, and ieee80211_csa_finish() runs only for an already-valid in-CSA arvif rather than as a write primitive from the overread.
- A:HAvailability impact, high
- A huge num_vdevs walks vdev_ids[] off the WMI skb while holding rcu_read_lock(), which can oops/panic on unmapped or KASAN-redzoned heap past the CE buffer and can stall RCU for a 32-bit iteration count, a full kernel availability loss.