CVE-2026-93805

Description

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.

Gravité et risque d'exploitation

CVE-2026-93805 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.17 %, ce qui la place devant 6.3 % des CVE référencées.

Que faire ?

• Vérifiez si Linux (versions <=6.1.*, <2.6.32, <=6.12.*, <ce2a3be6909462f49c34de96be71f0ad5f0d573f, 6.18.53, 0, <8f4127a93cf60d561ad39849a9ac763ba0e14db5, 6.6.158, <=6.6.*, 6.1.189, <d5e4586546974179feca305a94e07fac3e9727fe, <6bdf4dcff98df634e04ebf99f52027a48d7f78ff, <0ec738a0d361d7eb37188117166d201f9df622d3, <=6.18.*, 2.6.32, 5.15.222, 6829c878ecd24ff0ae41b4668c7e9d0f11b66942, <=*, <=5.15.*, <6eb4bd50be53f5afbabb3a3b5153276e08fa7a4a, 7.2, 6.12.111) est présent sur votre parc.
• Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
• À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
• Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références

• https://git.kernel.org/stable/c/6eb4bd50be53f5afbabb3a3b5153276e08fa7a4a
• https://git.kernel.org/stable/c/ce2a3be6909462f49c34de96be71f0ad5f0d573f
• https://git.kernel.org/stable/c/6bdf4dcff98df634e04ebf99f52027a48d7f78ff
• https://git.kernel.org/stable/c/0ec738a0d361d7eb37188117166d201f9df622d3
• https://git.kernel.org/stable/c/8f4127a93cf60d561ad39849a9ac763ba0e14db5
• https://git.kernel.org/stable/c/d5e4586546974179feca305a94e07fac3e9727fe