{
  "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.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()  ieee80211_monitor_select_queue() validates the skb length using skb-\u003elen before dereferencing pointers into skb-\u003edata to access the 802.11 header. However, skb-\u003elen includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb-\u003edata + len_rthdr may extend past the linear head buffer even though skb-\u003elen appears sufficient.  This leads to a slab-out-of-bounds read when accessing hdr-\u003eframe_control, as the kernel reads beyond the allocated skb head buffer:    BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220  syzbot has hit the same issues.  Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb-\u003elen before dereferencing skb-\u003edata pointers. This ensures the required bytes are actually present in the linear portion of the skb.  Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb-\u003elen to validate accesses to skb-\u003edata, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well.",
  "id": "DEBIAN-CVE-2026-98810",
  "modified": "2026-10-19T04:47:28.837887495Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98810"
    }
  ],
  "upstream": [
    "CVE-2026-98810"
  ]
}