Look up another CVE · open CVE-2026-68326 in the interactive tracker
CVE-2026-68326
wifi: mwifiex: bound uAP association event IEs to the event buffer
Published 2026-08-10 (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-68326 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-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: sinfo->assoc_req_ies = &event->data[len]; len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets").
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/uap_event.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-08-10 (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.26%, higher than 16.8% 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.5 | 5.10.265 | a616616b938f |
| 3.5 | 5.15.216 | 1ae00b6d9a6c |
| 3.5 | 6.1.183 | e7e93d3e8c24 |
| 3.5 | 6.6.148 | a3f47d7c75dd |
| 3.5 | 6.12.101 | ad26c75ae257 |
| 3.5 | 6.18.42 | d21464d93f8b |
| 3.5 | 7.1.6 | b6766d7ea43e |
| 3.5 | 7.2 | f0858bfc7d3c |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | 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:AAttack vector, adjacent network
- The event payload is the firmware's rendering of an over-the-air (re)association request received by the mwifiex uAP interface, with event->len being the TLV length covering that frame, so the triggering input comes from a station within 802.11 radio range. This matches the Adjacent treatment used for other frame/event-driven mwifiex defects (CVE-2024-46755, CVE-2023-53226).
- AC:LAttack complexity, low
- No race or attacker-uncontrollable state is involved: the attacker simply sends a crafted/oversized (re)association request to the AP, and the handler parses the resulting EVENT_UAP_STA_ASSOC unconditionally. The only precondition, an mwifiex interface in AP/uAP mode with ap_11n_enabled, is the normal steady state for tethering, Chromebook SoftAP and embedded AP deployments.
- PR:NPrivileges required, none
- EVENT_UAP_STA_ASSOC is generated at association time, before the WPA/EAPOL handshake, so the attacker needs no credentials on or accepted association with the target host. No host user account or capability is involved anywhere on the path.
- UI:NUser interaction, none
- The event is consumed autonomously by mwifiex_process_uap_event() in the driver's main work handler as soon as the firmware delivers it; no local user or administrator action is required beyond the AP already running.
- S:UScope, unchanged
- The out-of-bounds read, the underflowed length and the resulting corruption are all confined to the host kernel's own security authority within the mwifiex/cfg80211 code; no hypervisor, IOMMU or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- An over-claimed event->len makes assoc_req_ies_len describe memory past adapter->event_body[MAX_EVENT_SIZE], producing a slab-out-of-bounds read in cfg80211_find_ie() and, worse, causing nla_put() to copy up to tens of kilobytes of adjacent kernel slab memory into the NL80211_CMD_NEW_STATION notification delivered to userspace — an unbounded kernel heap disclosure, not a few stray bytes.
- I:HIntegrity impact, high
- An event->len below the header makes the int subtraction negative and wrap in size_t; that value reaches nla_put(), where nla_total_size() of the negative length evaluates to 0 and passes the tailroom check, so __nla_put()'s memcpy() runs with the negative length widened to a huge size_t — an unbounded out-of-bounds write past the netlink skb. Driver 11n/AMSDU state is also set from out-of-bounds data.
- A:HAvailability impact, high
- The commit documents a reproducible KASAN slab-out-of-bounds in cfg80211_find_ie, and the underflow path drives a memcpy of a near-2^64 length that guarantees an immediate kernel panic. The condition can be re-triggered at will by repeating the association attempt.