{"cve":"CVE-2026-93805","nvd":{"published":"2026-09-24T17:17:13.460","modified":"2026-10-03T11:17:50.190","status":"Received","description":"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 >= 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 < 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 < 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 >= 2).\n   The len >= 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.","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/0ec738a0d361d7eb37188117166d201f9df622d3","https://git.kernel.org/stable/c/6bdf4dcff98df634e04ebf99f52027a48d7f78ff","https://git.kernel.org/stable/c/6eb4bd50be53f5afbabb3a3b5153276e08fa7a4a","https://git.kernel.org/stable/c/8f4127a93cf60d561ad39849a9ac763ba0e14db5","https://git.kernel.org/stable/c/ce2a3be6909462f49c34de96be71f0ad5f0d573f"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:56:02.509636177+00:00"},"epss":{"cve":"CVE-2026-93805","score":0.00173,"percentile":0.06627,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}