CVE-2026-80944
moderateStack corruption in Linux kernel mwifiex driver via interrupted firmware command waits
A use-after-return flaw in the Linux kernel's mwifiex Marvell WiFi driver allows a late firmware response to write through a stale pointer into a caller's stack buffer. Synchronous commands store caller-provided stack-allocated buffers in cmd_node->data_buf; if the wait on the command is interrupted (e.g., by a signal during repeated association/disassociation cycles), the caller returns and its stack object goes out of scope while the command is still current, so the eventual firmware response handler copies data into that dead stack address. This was observed in the wild as a kernel panic ('stack-protector: Kernel stack is corrupted') on an NXP i.MX8MP board with an 88W8997 chip, where a late VERSION_EXT response wrote firmware-string fragments into stale stack memory. An attacker with local, low-privileged access who can drive and time WiFi association cycles against affected hardware could potentially leverage the corruption for kernel memory disclosure, modification, or privilege escalation (CVSS 3.1: 7.8, local vector). No public proof of concept or in-the-wild exploitation is known.
What to do: Upgrade to a kernel release containing the mwifiex fix, which detaches the caller-owned data buffer from the still-current command after an interrupted or timed-out wait; embedded vendors building on NXP BSPs should pull the patch into their trees. On unpatched systems, avoid workloads that hammer WiFi association/disassociation cycles on mwifiex hardware and monitor for 'cmd_wait_q terminated: -512' followed by stack-protector kernel panics as an indicator. No exploitation has been observed, so patching on normal maintenance cycles is reasonable.
| Linux kernel (drivers/net/wireless/marvell/mwifiex) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.