Look up another CVE · open CVE-2026-74407 in the interactive tracker
CVE-2026-74407
wifi: ath11k: cancel SSR work items during PCI shutdown
Published 2026-08-15 (2 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-2026-74407 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 | 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.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
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/ath11k/mhi.c
drivers/net/wireless/ath/ath11k/pci.c
- What this is
- QUALCOMM ATHEROS ATH11K WIRELESS DRIVERMAINTAINERS section matched on drivers/net/wireless/ath/ath11k/ · linux-wireless@vger.kernel.org · Supported
- Kernel module
- ath11k_pci
Check it on the machine
grep -wE 'CONFIG_ATH11K|CONFIG_ATH11K_PCI|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 ath11k_pciPrints 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_ATH11K, CONFIG_ATH11K_PCI, 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-08-15 (2 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.38%, higher than 29.9% 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.19 | 6.18.53 | 6dd3701facc0 |
| 5.19 | 7.1.5 | 53dd29e8aeb2 |
| 5.19 | 7.2 | 8c79aac429b5 |
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:AAttack vector, adjacent network
- WiFi ath11k PCI/MHI devices (QCA6390/WCN6855 laptops, workstations, gateways) enter SSR when WLAN firmware faults; MHI RDDM interrupts queue reset_work recovery that races kernel_restart PCI shutdown (ath11k_pci_shutdown) on the same driver.
- AC:LAttack complexity, low
- An adjacent attacker controls SSR timing by repeatedly inducing firmware crashes via crafted/malicious 802.11 traffic, keeping reset_work active until shutdown overlaps; this is an attacker-driven race, not luck-dependent memory layout or rare kernel config.
- PR:NPrivileges required, none
- No Linux account or kernel capability is needed to trigger the SSR leg—firmware crash/RDDM recovery is driven by over-the-air WLAN events; concurrent device_shutdown during automated maintenance or fleet reboots can overlap without attacker CAP_SYS_BOOT.
- UI:NUser interaction, none
- Only an active ath11k WLAN interface is required (default on WiFi-equipped systems); no victim clicks, network joins, or manual reboot actions are needed because unattended updates and scheduled maintenance reboots can overlap SSR automatically.
- S:UScope, unchanged
- Impact is kernel panic/oops from unsynchronized MHI DMA teardown within the host kernel security boundary; this does not cross VM, container, or IOMMU trust domains.
- C:HConfidentiality impact, high
- Concurrent mhi_unprepare_after_power_down/mhi_deinit_dev_ctxt from reset_work and ath11k_pci_shutdown can double-free coherent DMA rings/contexts or dereference freed MHI state, enabling arbitrary kernel memory reads and information disclosure.
- I:HIntegrity impact, high
- Racing power-down paths free the same MHI DMA-backed ring/context memory twice, corrupting kernel DMA allocator metadata and enabling controlled reallocation for arbitrary kernel writes, control-flow hijack, and privilege escalation.
- A:HAvailability impact, high
- NULL pointer dereference and/or double dma_free in mhi_deinit_dev_ctxt during PCI shutdown overlapping SSR reliably causes kernel oops/panic, denying availability and potentially aborting reboot on affected Qualcomm ath11k PCI systems.