CVE-2026-68326 in Linux
Summary
by MITRE • 08/10/2026
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").
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the linux kernel's mwifiex driver, specifically in how it processes association events from wireless firmware operating in access point mode. The flaw manifests during handling of EVENT_UAP_STA_ASSOC through the mwifiex_process_uap_event() function where association request information elements are extracted from a fixed-size buffer named adapter->event_body. This buffer has a defined maximum size of MAX_EVENT_SIZE and is embedded within a dynamically allocated structure mwifiex_adapter. The function directly uses event->len, a field provided by the firmware without validation, to calculate pointer positions and lengths for these information elements.
The core technical issue stems from unchecked arithmetic operations involving event->len which can be manipulated by malicious or faulty hardware devices connected via USB, SDIO, or PCIe interfaces. When the firmware reports an event length that exceeds the actual data received, or when it underreports such that the calculated offset becomes negative due to integer arithmetic, the system computes invalid memory addresses. Specifically, the subtraction operation (u8 )sinfo->assoc_req_ies - (u8 )&event->frame_control results in a negative value when event->len is smaller than expected, leading to a massive size_t value being stored in assoc_req_ies_len. This unvalidated length parameter then gets passed to cfg80211_find_ie() during the processing of station associations, causing out-of-bounds memory reads that trigger kernel memory safety violations such as KASAN reports indicating slab-out-of-bounds access.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation or system instability. The malicious device could cause arbitrary code execution by carefully crafting event lengths that force the kernel to read from memory locations outside the intended buffer boundaries. This is particularly concerning because the affected code path operates in kernel space with elevated privileges, and the exploitation can occur during normal wireless operations when the interface is operating in AP/uAP mode. The vulnerability affects all mwifiex implementations across different transport layers including USB, SDIO, and PCIe, making it broadly applicable to various hardware configurations.
The recommended mitigation involves implementing strict bounds checking on event->len before any pointer arithmetic calculations are performed. This validation should ensure that the reported length does not underflow the event header size nor exceed the maximum capacity of the fixed-size event_body buffer. The fix must be implemented at the specific event handler level rather than at the generic receive path since event->len represents a payload-specific field within the event structure rather than transport-level frame metadata. The validation logic should compare against MAX_EVENT_SIZE to prevent both underflow conditions that cause negative offsets and overflow conditions that extend beyond the allocated buffer boundaries. This approach mirrors similar fixes previously implemented in commit 119585281617 which addressed comparable out-of-bounds access issues during packet reception, establishing a consistent pattern for handling such vulnerabilities within the mwifiex driver ecosystem. The solution aligns with common security practices for preventing integer overflows and buffer overflows as specified in CWE categories related to improper input validation and memory safety violations.
This vulnerability demonstrates how embedded firmware components can introduce critical security flaws when device communication interfaces lack proper input sanitization. The issue represents a classic case of insufficient bounds checking in kernel drivers where user-supplied data from hardware devices is trusted without adequate validation, creating potential for exploitation through crafted hardware responses. The fix emphasizes the importance of defensive programming practices in kernel space code and highlights the need for comprehensive testing of edge cases involving malformed or malicious inputs from hardware peripherals. The vulnerability's presence in multiple transport protocols suggests that similar issues may exist across other driver components that process firmware-provided data without proper bounds validation, warranting broader security audits of the mwifiex subsystem for similar patterns.