Look up another CVE · open CVE-2026-80944 in the interactive tracker
CVE-2026-80944
wifi: mwifiex: Detach sync cmd buffer on interrupted wait
Published 2026-09-11 (37 days 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-80944 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| 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. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> "bF878X,\0" which is a fragment of the VERSION_EXT firmware string exposed as debugfs "verext": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> "153.7\0$" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.
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/marvell/mwifiex/sta_ioctl.c
- What this is
- MARVELL MWIFIEX WIRELESS DRIVERMAINTAINERS section matched on drivers/net/wireless/marvell/mwifiex/ · linux-wireless@vger.kernel.org · Odd Fixes
- Kernel module
- mwifiex
Check it on the machine
grep -wE 'CONFIG_MWIFIEX|CONFIG_WLAN|CONFIG_WLAN_VENDOR_MARVELL' /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 mwifiexPrints 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, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, loong64/loong64, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_MWIFIEX, CONFIG_WLAN, CONFIG_WLAN_VENDOR_MARVELL
- 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-11 (37 days 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.13%, higher than 2.3% 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 |
|---|---|---|
| 3.15 | 5.10.270 | 8c67b8c50286 |
| 3.15 | 5.15.221 | 9024c7729eb5 |
| 3.15 | 6.1.188 | 9e06c9c8a1f1 |
| 3.15 | 6.6.157 | f2134d6ff30c |
| 3.15 | 6.12.109 | 20ee9c03f261 |
| 3.15 | 6.18.50 | b1bbeb8970ee |
| 3.15 | 7.2.4 | d29a165588b6 |
| 3.15 | 7.3 | ef06882c7d8a |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 stale data_buf write is reached from local cfg80211/nl80211 and debugfs paths that call mwifiex_send_cmd(..., sync) and sleep in mwifiex_wait_queue_complete(), not from parsing received 802.11 frames, so this is a local syscall/ioctl issue rather than an adjacent RF or remote network vector.
- AC:LAttack complexity, low
- The attacker issues a synchronous mwifiex command and signals the waiting thread (or races a second nl80211 dump against an in-flight command); cancel_all_pending_cmd() intentionally leaves curr_cmd queued for the firmware reply, so the late write-through data_buf does not depend on an uncontrolled race or layout.
- PR:LPrivileges required, low
- NL80211_CMD_GET_STATION is unprivileged and still sends sync firmware commands whose interrupted wait runs mwifiex_cancel_all_pending_cmd() against curr_cmd; remain-on-channel and other cfg80211 ops need only CAP_NET_ADMIN, which is a low-privileged local role on mwifiex phones, Chromebooks, and embedded boards rather than init-namespace root.
- UI:NUser interaction, none
- The attacker performs the nl80211 or debugfs request and delivers the interrupting signal themselves; no separate victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- The corruption hits host kernel stack or heap in the mwifiex command-response path and stays within the same kernel security authority, yielding local privilege escalation or a host panic rather than a VM, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- A late firmware response memcpy's through the dangling cmd_node->data_buf into reused kernel stack (VERSION_EXT copies 128 bytes) or a kfree'd testmode hostcmd buffer (up to 2048 bytes), a use-after-free write that can be reclaimed for arbitrary kernel read.
- I:HIntegrity impact, high
- The same stale-pointer write smashes kernel stack frames or a freed heap object, which is exploitable for control-flow hijacking; the observed VERSION_EXT ASCII overwrite already tripped the stack protector.
- A:HAvailability impact, high
- The bug was observed as a kernel paging fault and stack-protector panic (cmd_wait_q terminated: -512, Kernel panic - not syncing: stack-protector: Kernel stack is corrupted), which is a full host availability loss.