{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 \u003e= 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 \u003c 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 \u003c 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 \u003e= 2).    The len \u003e= 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.",
  "id": "DEBIAN-CVE-2026-93805",
  "modified": "2026-09-26T08:47:41.243834908Z",
  "published": "2026-09-24T17:17:13.460Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-93805"
    }
  ],
  "upstream": [
    "CVE-2026-93805"
  ]
}