{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.176-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.88-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  wifi: ath5k: do not access array OOB  Vincent reports: \u003e The ath5k driver seems to do an array-index-out-of-bounds access as \u003e shown by the UBSAN kernel message: \u003e UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 \u003e index 4 is out of range for type 'ieee80211_tx_rate [4]' \u003e ... \u003e Call Trace: \u003e  \u003cTASK\u003e \u003e  dump_stack_lvl+0x5d/0x80 \u003e  ubsan_epilogue+0x5/0x2b \u003e  __ubsan_handle_out_of_bounds.cold+0x46/0x4b \u003e  ath5k_tasklet_tx+0x4e0/0x560 [ath5k] \u003e  tasklet_action_common+0xb5/0x1c0  It is real. 'ts-\u003ets_final_idx' can be 3 on 5212, so:    info-\u003estatus.rates[ts-\u003ets_final_idx + 1].idx = -1; with the array defined as:    struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is:    #define IEEE80211_TX_MAX_RATES  4 is indeed bogus.  Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES).  Note: The effect of the OOB write is negligible. It just overwrites the next member of info-\u003estatus, i.e. ack_signal.",
  "id": "DEBIAN-CVE-2026-46307",
  "modified": "2026-09-14T16:47:34.595997569Z",
  "published": "2026-06-08T17:16:49.547Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46307"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46307"
  ]
}