CVE-2026-68326: wifi: mwifiex: bound uAP association event IEs to the event buffer
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: bound uAP association event IEs to the event buffer
mwifiexprocessuapevent() handles EVENTUAPSTAASSOC by exposing the (re)association request IEs that the firmware copies into the event:
sinfo->assocreqies = &event->data[len]; len = (u8 )sinfo->assocreqies - (u8 )&event->framecontrol; sinfo->assocreqieslen = le16tocpu(event->len) - (u16)len;
event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assocreqies points into adapter->eventbody[MAXEVENTSIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiexadapter.
On the ap11nenabled path mwifiexsetstahtcap() walks these IEs with cfg80211findie(), whose foreachelement() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assocreqieslen describe IEs that extend past eventbody, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211findie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge sizet when stored in assocreqieslen. The same length is handed to cfg80211newsta(), so a more modest over-claim can also copy stale eventbody bytes into the NL80211CMDNEWSTATION 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 eventbody[] buffer the event was copied into. event->len here is struct mwifiexassocevent.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 MWIFIEXTYPEEVENT receive path, which only sees the event cause and the transport frame length. The bound is against eventbody[MAXEVENTSIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in eventskb, PCIe strips it via skbpull), whereas eventbody 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux kernel mwifiexto a version that resolves this vulnerability.Patch commit 119585281617 - Configuration
In mwifiex uAP/AP association event processing (EVENT_UAP_STA_ASSOC), validate struct mwifiex_assoc_event.len (device-supplied) before using it to compute assoc_req_ies_len and before walking/parsing IEs. Reject lengths that underflow or would make assoc_req_ies extend past adapter->event_body[MAX_EVENT_SIZE], so cfg80211_find_ie() never iterates over out-of-bounds IE data.
mwifiex (uAP/AP association event handling) Validate event->len before parsing assoc_req_ies IEs = reject underflow/overflow lengths that would place IEs outside event_body[MAX_EVENT_SIZE]
Event History
Frequently Asked Questions
What is the severity of CVE-2026-68326?
CVE-2026-68326 has a risk rating of 33, indicating a moderate severity level.
How does CVE-2026-68326 affect Linux kernel users?
CVE-2026-68326 affects users by exposing potentially sensitive (re)association request information through mwifiex_process_uap_event() in the Linux kernel.
What are the implications of CVE-2026-68326 for wireless networks?
CVE-2026-68326 may lead to security risks where malicious users can exploit the exposed association request information in wireless networks.
How can I fix CVE-2026-68326?
Fixing CVE-2026-68326 involves updating the Linux kernel to a version where the vulnerability has been resolved.
Is there a workaround for CVE-2026-68326 if I can't update the kernel?
Currently, there are no documented workarounds for CVE-2026-68326, so updating is the recommended action.