Cloudanix VulnDB

CVE-2026-68326

High · 8.8

CVSS

8.8

EPSS

0.3%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how certain wireless chips report new device connections to the Linux kernel can let an attacker on the same network read internal memory or crash the system.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Unvalidated firmware-supplied event length in mwifiex_process_uap_event allows either a slab-out-of-bounds read when walking association IEs with cfg80211_find_ie or an integer underflow that produces a huge assoc_req_ies_len passed to cfg80211_new_sta, all within the fixed-size event_body buffer of the mwifiex_adapter object.

Why it matters to the business

Attackers on the same Wi-Fi segment can read kernel memory or trigger crashes on affected Linux systems running the mwifiex driver in access-point mode, potentially leading to information disclosure or denial of service that disrupts wireless infrastructure.

How an attack unfolds

A malicious or malfunctioning mwifiex USB/SDIO/PCIe device sends an EVENT_UAP_STA_ASSOC frame whose len field is either larger than the copied event or small enough to underflow the header subtraction; the driver then dereferences IEs outside the event buffer or supplies an oversized length to cfg80211, resulting in out-of-bounds memory access while the interface operates in AP/uAP mode.

How to fix it

Update the Linux kernel to a version containing the bounds check on event->len before the subtraction and pointer assignment in mwifiex_process_uap_event; apply the same style of receive-path validation already present for packet lengths.

How to confirm the fix worked

Confirm the patch by inspecting mwifiex_process_uap_event for an explicit check that rejects lengths which would underflow the header or place assoc_req_ies past the end of event_body[MAX_EVENT_SIZE]; recompile and load the driver then exercise AP association events while monitoring for KASAN slab-out-of-bounds reports.

Typical attack path

  1. Attacker gains control of or emulates a mwifiex wireless device on the USB/SDIO/PCIe bus.
  2. Device is placed into AP/uAP mode on the target system.
  3. Malicious firmware emits an EVENT_UAP_STA_ASSOC event with crafted len value.
  4. mwifiex_process_uap_event performs unchecked arithmetic and pointer arithmetic on the event.
  5. cfg80211_find_ie or cfg80211_new_sta walks or copies memory outside the allocated event_body slab object.

How to detect it

Search kernel logs for KASAN reports citing cfg80211_find_ie and slab-out-of-bounds in the mwifiex path; monitor for unexpected NL80211_CMD_NEW_STATION messages containing large or malformed IE blobs; review dmesg around mwifiex_process_uap_event calls when the interface is in AP mode.

  • KASAN: slab-out-of-bounds in cfg80211_find_ie
  • mwifiex_process_uap_event
  • EVENT_UAP_STA_ASSOC

What your security team should do

  • Prioritize kernel updates on any system exposing mwifiex-based Wi-Fi in AP mode.
  • Disable AP/uAP functionality on mwifiex hardware until patched if the interface is not required.
  • Add kernel memory-safety tooling (KASAN, KMSAN) to CI builds that exercise the mwifiex event path.

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer 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").

Affected packages

Ecosystem Package Introduced Fixed