{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.190-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.113-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.9-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  af_packet: fix integer overflow in prb_calc_retire_blk_tmo()  prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:          mbits = (blk_size_in_bytes * 8) / (1024 * 1024);  If I'm reading the validation right, tp_block_size is user controlled and packet_set_ring() only rejects values that are \u003c= 0 as int or not page aligned, so a 256MiB block goes right through (and alloc_one_pg_vec_page() even has a vzalloc fallback for it). 0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps (div == 1) the function ends up returning -2047.  The condition is actually (8 * size) mod 2^32 \u003e= 2^31 \u0026\u0026 div == 1, so the trigger set is [256,512), [768,1024), [1280,1536) and [1792,2048) MiB. Other sizes wrap to non-negative values and faster links divide the unsigned value back below 2^31, which is why this doesn't blow up for everyone.  What makes it fatal is what happens next in init_prb_bdqc():          p1-\u003einterval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));         hrtimer_start(\u0026p1-\u003eretire_blk_timer, p1-\u003einterval_ktime,                       HRTIMER_MODE_REL_SOFT);  A negative relative timeout expires immediately. The callback unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns the negative interval into hrtimer_resolution:          if (interval \u003c hrtimer_resolution)                 interval = hrtimer_resolution;  So the SOFT timer re-fires at the maximum rate forever, holding sk_receive_queue.lock each pass. One CPU spins in softirq until the socket is closed. Repeat with more rings and the machine is gone.  The overflow itself is ancient - it was introduced together with TPACKET_V3 in f6fb8f100b80 (\"af-packet: TPACKET_V3 flexible buffer implementation.\"). Its effect prior to f7460d2989fa (\"net: af_packet: Use hrtimer to do the retire operation\", v6.18) was not as clear-cut, though: the return value was stored into an unsigned short retire_blk_tov, so a negative result was truncated, and a 0-jiffy delay loop could be programmed as well. Neither is nearly as detrimental as the immediate maximum-rate spin the hrtimer conversion turned it into.  (Unrelated to CVE-2019-20812 - that one was the ethtool failure path returning 0, which now returns DEFAULT_PRB_RETIRE_TOV.)  Reproducer, needs CAP_NET_RAW (a --network host container has it by default) and a 1 Gbps NIC (QEMU e1000 works):          int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));         bind(fd, ...);         int v = TPACKET_V3;         setsockopt(fd, SOL_PACKET, PACKET_VERSION, \u0026v, sizeof(v));         struct tpacket_req3 req = {                 .tp_block_size = 0x10000000,                 .tp_block_nr = 1,                 .tp_frame_size = 2048,                 .tp_frame_nr = 0x10000000 / 2048,                 .tp_retire_blk_tov = 0,         };         setsockopt(fd, SOL_PACKET, PACKET_RX_RING, \u0026req, sizeof(req));  Compute in 64 bits instead. The operands are already bounded by the existing validation, so nothing else changes. If you'd prefer a different fix, just say so and I'll respin.",
  "id": "DEBIAN-CVE-2026-98547",
  "modified": "2026-10-19T04:47:40.876615284Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98547"
    }
  ],
  "upstream": [
    "CVE-2026-98547"
  ]
}