CVE-2026-80944

What it actually does

The mwifiex driver keeps a pointer (cmd_node->data_buf) to a caller-supplied synchronous-command buffer that is often allocated on the kernel stack. If wait_event_interruptible_timeout() is interrupted or times out, the waiting caller can return and destroy that stack object while the firmware command is still current. A late firmware response then copies data through the dangling pointer into freed stack memory, producing a use-after-free write, stack-protector panics, and kernel paging faults. Given local, low-privilege, high CIA impact (CVSS 7.8), the same corruption could in principle overwrite kernel control data rather than only crash.

Why it matters to the business

Linux systems and embedded products that use the mwifiex wireless driver (Marvell/NXP chipsets such as 88W8997, common on industrial, automotive, and IoT boards) can kernel-panic during ordinary associate/disassociate cycles, causing unplanned reboots and loss of wireless connectivity. A local low-privileged user could theoretically convert the stack corruption into privilege escalation or host takeover. Exploit maturity is none, EPSS is very low (~0.0018 and flat over 30 days), and the issue is not in CISA KEV, so mass-exploitation urgency is low; the practical risk is instability and local privilege-escalation potential on multi-user or untrusted-local-access devices. Apply vendor kernel updates in the normal patch window, faster where untrusted local users share mwifiex hosts.

How an attack unfolds

An attacker who already has a local unprivileged account on a Linux host with an mwifiex-managed adapter exercises synchronous firmware commands (for example by driving association, disassociation, or other driver command paths that pass stack-backed buffers). They arrange for the command wait to be interrupted while firmware is still processing so the caller returns and the stack buffer is gone, but the command node still points at it. A delayed firmware response—observed in crashes as a VERSION_EXT/verext string write—then lands in stale stack memory. The usual result is an immediate kernel panic (stack-protector or bad paging address). A capable attacker might try to influence timing and written contents to corrupt kernel state for local privilege escalation. No public exploit, no named threat actors, and no KEV/ransomware use are reported.

How to fix it

Apply the upstream Linux kernel fix that, after cancelling pending commands on an interrupted or timed-out wait, detaches the caller-owned data buffer from the still-current command so a late response cannot write through an expired pointer. Upgrade to a distribution or vendor kernel that includes the mwifiex change titled along the lines of “Detach sync cmd buffer on interrupted wait.” For BSP/Yocto/Android/i.MX and other vendor trees, obtain the corresponding backport from the silicon or OS vendor. If an immediate kernel update is not possible, reduce exposure by unloading mwifiex where the adapter is unused, restricting unprivileged netlink/ioctl wireless management, and avoiding automated association/disassociation loops that interrupt sync command waits. Exact package versions were not published with this record; track your distro’s kernel changelog for the mwifiex data_buf detach fix.

How to confirm the fix worked

Confirm the running kernel (uname -r and distro changelog or git history) contains the mwifiex patch that detaches cmd_node->data_buf on interrupted/timed-out sync waits. Verify whether mwifiex is loaded (lsmod, sysfs) and which adapters use it. In a lab only, repeat previously panicking associate/disassociate stress; a fixed kernel should complete those waits without stack-protector panics or cmd_wait_q terminated:-512 followed by a paging fault. Review dmesg/journal and kdump/pstore from before the upgrade for historical exposure. Unfixed vendor BSPs should be treated as still exposed even if the upstream tree is patched.

Typical attack path

1. Gain local unprivileged code execution or a shell on a Linux system whose wireless adapter is bound to mwifiex.
2. Trigger mwifiex synchronous firmware commands that stash a stack-allocated caller buffer in cmd_node->data_buf (association, disassociation, or similar command wait paths).
3. Cause the command wait to be interrupted or time out so the caller returns while the command remains current.
4. Rely on a late firmware response (for example VERSION_EXT) to write through the stale data_buf into freed kernel stack.
5. Use the resulting stack corruption to crash the host or, if control data can be overwritten, attempt local privilege escalation to kernel/root.

How to detect it

This issue typically surfaces as a kernel oops/panic rather than a distinctive network payload. Search dmesg, journalctl -k, kdump/vmcore, pstore, and serial console logs for mwifiex command-wait interruption immediately followed by stack-protector failure or an unhandleable paging request. The crash path in the advisory shows cmd_wait_q terminated with -512 (EINTR), then a bad virtual address and “Kernel panic - not syncing: stack-protector: Kernel stack is corrupted.” Faulting addresses may decode as little-endian fragments of the firmware VERSION_EXT/verext string (debugfs verext). Correlate with mwifiex loaded, 88W8997 or similar adapters, and repeated association/disassociation around the timestamp. There are no public exploit kits or named-actor TTPs; treat matching panics as evidence the race occurred, not proof of intentional privilege escalation.

• cmd_wait_q terminated: -512
• Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
• Unable to handle kernel paging request at virtual address
• wifi: mwifiex
• mwifiex
• verext
• VERSION_EXT
• w8997o-V4
• RF878X
• 88W8997

What your security team should do

• Inventory Linux hosts and embedded images that load mwifiex or use Marvell/NXP 88W8xxx adapters and flag multi-user or untrusted-local-access systems first.
• Deploy vendor/distro kernels that include the mwifiex sync-command data_buf detach fix; chase BSP backports for i.MX and similar products.
• Until patched, restrict unprivileged wireless configuration and do not run untrusted local workloads on mwifiex hosts.
• Alert on kernel panics matching mwifiex wait interruption plus stack-protector corruption; treat those as crash/exposure evidence, not confirmed targeted exploitation.
• Do not emergency-break change windows solely on EPSS/KEV (both low/false), but do not defer patches on crash-prone wireless fleets.
• Track upstream and vendor advisories for follow-on mwifiex memory-safety fixes in the same command-wait path.