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: