CVE-2026-93805 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present.
The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer.
Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed.
Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in the Linux kernel's wireless configuration subsystem, specifically within the cfg80211 module, represents a critical out-of-bounds read condition arising from insufficient validation of Management Control Element (MLME) frame lengths prior to data access. This flaw affects both reception and transmission paths via the functions cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt(). The core technical deficiency lies in the sequence of operations performed on incoming wireless frames. Previously, these functions would invoke tracepoints before validating whether the frame length was sufficient to contain the expected fixed fields for a given subtype. Furthermore, while there was a check ensuring the length was at least two bytes to safely read the frame-control field, this threshold is far too low for many management subtypes which require significantly more data to be present in their headers and bodies.
The operational impact of this vulnerability is most severe when processing frames from specific drivers such as mwifiex. In a concrete scenario involving the mwifiex driver, the function mwifiex_process_mgmt_packet() passes frames to cfg80211_rx_mlme_mgmt() after stripping a firmware length prefix and removing an optional fourth address field. This process can result in a packet with exactly twenty-four bytes of payload remaining. A standard three-address IEEE 802.11 management header occupies precisely these twenty-four bytes, leaving no room for additional fields such as the reason code required by deauthentication frames. Because the existing validation only checked if the length was greater than or equal to two, it failed to detect that the frame was too short for its specific subtype. Consequently, when cfg80211_process_deauth() attempted to read the reason_code field at an offset of twenty-four bytes from a buffer that ended exactly at that point, it triggered an out-of-bounds memory access. This type of vulnerability aligns with CWE-125, which describes Out-of-Bounds Read vulnerabilities where software reads data past the end or before the beginning of the intended buffer.
From a security perspective, this flaw allows for potential information disclosure if the kernel accesses uninitialized memory adjacent to the packet buffer and subsequently processes that data. In more complex exploitation scenarios involving crafted wireless frames from malicious access points or stations, an attacker could potentially leverage this out-of-bounds read to leak sensitive kernel memory contents into user space or trigger a denial of service through a kernel panic caused by accessing invalid memory pages. This behavior is consistent with ATT&CK technique T1082, which involves System Information Discovery, as the vulnerability facilitates reading system memory that should not be accessible during normal packet processing operations. The lack of proper bounds checking on subtype-specific minimum frame sizes creates an attack surface where malformed or truncated frames can bypass standard validation logic and reach deep into kernel handlers with insufficient data integrity guarantees.
The resolution implemented in this patch addresses the root cause by introducing a rigorous frame-control length gate followed by explicit validation of each subtype's minimum required frame size within an if-else-if chain that mirrors the dispatch logic used for handling different management subtypes. This ensures that tracepoints are only invoked after it is confirmed that the frame contains all necessary fixed fields, thereby preventing any access to memory beyond the allocated buffer boundaries. Additionally, the patch modifies the behavior of cfg80211_tx_mlme_mgmt(), which previously routed every non-deauthentication subtype through disassociation handling logic; it now silently ignores unrecognized subtypes, reducing unnecessary processing and potential side effects from malformed transmission requests.
Regarding mitigations and operational adjustments, the developers have made specific changes to warning mechanisms that affect system logging behavior. The previous WARN_ON(len < 2) check has been removed because it only guarded the initial frame-control read rather than the subtype-specific fixed fields, meaning it did not catch the actual out-of-bounds reads triggered by frames of two bytes or more but structurally insufficient for their type. While a len >= 2 check remains in place to prevent dereferencing an invalid frame_control pointer, the associated warning is omitted. This design choice reflects a security best practice where malformed frames received from drivers are dropped silently rather than generating kernel backtraces that could clutter logs or potentially expose internal state information through verbose error messages. System administrators and developers should ensure their wireless driver implementations strictly adhere to IEEE 802.11 frame structure requirements before passing packets to the cfg80211 subsystem, as this patch shifts more responsibility onto drivers to provide well-formed frames while ensuring the core kernel code performs comprehensive validation regardless of input source trustworthiness.