{"id":"CVE-2026-93805","summary":"wifi: cfg80211: validate rx/tx MLME callback frame lengths before access","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: validate rx/tx MLME callback frame lengths before access\n\ncfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints\nbefore rejecting frames shorter than the frame-control field. After\nthat, they only require len \u003e= 2 before dispatching into subtype\nhandlers that assume their fixed fields are present.\n\nThe frames that trip this are not shorter than 2 bytes; they are short\nrelative to their subtype. mwifiex is a concrete in-tree example on the\nlength side: mwifiex_process_mgmt_packet() only requires a 4-address\nieee80211_hdr plus the 2-byte firmware length prefix before handing the\nframe to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and\nremoving addr4, pkt_len can be exactly 24: a bare 3-address management\nheader with no reason-code body. The existing WARN_ON(len \u003c 2) does not\nfire on such a frame, and cfg80211_process_deauth() then reads\nu.deauth.reason_code as a two-byte access starting at offset 24,\nimmediately past the 24-byte buffer.\n\nAdd a frame-control length gate, then validate each subtype's minimum\nframe size in an if/else-if chain that mirrors the dispatch logic. Trace\nonly after the frame is known to be well-formed.\n\nSide effects of this change:\n - The WARN_ON(len \u003c 2) is dropped. It only guarded the frame_control\n   read, never the subtype fixed fields, and it does not fire on the\n   frames that actually trigger the out-of-bounds read (which are \u003e= 2).\n   The len \u003e= 2 check is kept as the guard before dereferencing\n   frame_control, but without the warning: these are exported callbacks\n   and a malformed frame from a driver should be dropped silently rather\n   than backtraced.\n - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype\n   through disassociation handling; it now silently ignores unrecognised\n   subtypes.","modified":"2026-09-26T03:48:26.831840607Z","published":"2026-09-24T16:02:39.248Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93805.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/0ec738a0d361d7eb37188117166d201f9df622d3"},{"type":"WEB","url":"https://git.kernel.org/stable/c/8f4127a93cf60d561ad39849a9ac763ba0e14db5"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d5e4586546974179feca305a94e07fac3e9727fe"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93805.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93805"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"6829c878ecd24ff0ae41b4668c7e9d0f11b66942"},{"fixed":"0ec738a0d361d7eb37188117166d201f9df622d3"},{"fixed":"8f4127a93cf60d561ad39849a9ac763ba0e14db5"},{"fixed":"d5e4586546974179feca305a94e07fac3e9727fe"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93805.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.6.32"},{"fixed":"6.12.111"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.53"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93805.json"}}],"schema_version":"1.9.0"}