CVE-2026-93805: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
cfg80211rxmlmemgmt() and cfg80211txmlmemgmt() 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: mwifiexprocessmgmtpacket() only requires a 4-address ieee80211hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211rxmlmemgmt(). After stripping the length prefix and removing addr4, pktlen can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARNON(len < 2) does not fire on such a frame, and cfg80211processdeauth() then reads u.deauth.reasoncode 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 WARNON(len < 2) is dropped. It only guarded the framecontrol 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 framecontrol, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211txmlmemgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt(), add a frame-control length gate before dereferencing frame_control, then validate each management-frame subtype's minimum fixed-field length before dispatching to subtype handlers; silently drop malformed frames, including frames shorter than the frame-control field and subtype frames missing required fields such as the 2-byte deauthentication reason code.
Event History
Frequently Asked Questions
Which driver path is explicitly identified as able to pass an undersized management frame to cfg80211?
The in-tree mwifiex path is identified. mwifiex_process_mgmt_packet() can pass a frame that becomes a 24-byte, three-address management header after its firmware length prefix and addr4 are removed.
Would the existing short-frame warning detect the described malformed frame?
No. The existing WARN_ON only checks for frames shorter than 2 bytes, while the described frame is 24 bytes long but lacks the subtype-specific reason-code field.
What happens when the affected deauthentication handling receives the 24-byte frame?
cfg80211_process_deauth() reads the two-byte reason_code at offset 24, immediately beyond the end of the 24-byte buffer. The resolved change adds frame-control and subtype-specific minimum-length validation before dispatch.