{"id":"AZL-108659","summary":"CVE-2026-98547 affecting package kernel 6.6.157.1-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix integer overflow in prb_calc_retire_blk_tmo()\n\nprb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:\n\n        mbits = (blk_size_in_bytes * 8) / (1024 * 1024);\n\nIf I'm reading the validation right, tp_block_size is user\ncontrolled and packet_set_ring() only rejects values that are \u003c= 0\nas int or not page aligned, so a 256MiB block goes right through\n(and alloc_one_pg_vec_page() even has a vzalloc fallback for it).\n0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps\n(div == 1) the function ends up returning -2047.\n\nThe condition is actually (8 * size) mod 2^32 \u003e= 2^31 && div == 1,\nso the trigger set is [256,512), [768,1024), [1280,1536) and\n[1792,2048) MiB. Other sizes wrap to non-negative values and faster\nlinks divide the unsigned value back below 2^31, which is why this\ndoesn't blow up for everyone.\n\nWhat makes it fatal is what happens next in init_prb_bdqc():\n\n        p1-\u003einterval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));\n        hrtimer_start(&p1-\u003eretire_blk_timer, p1-\u003einterval_ktime,\n                      HRTIMER_MODE_REL_SOFT);\n\nA negative relative timeout expires immediately. The callback\nunconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns\nthe negative interval into hrtimer_resolution:\n\n        if (interval \u003c hrtimer_resolution)\n                interval = hrtimer_resolution;\n\nSo the SOFT timer re-fires at the maximum rate forever, holding\nsk_receive_queue.lock each pass. One CPU spins in softirq until the\nsocket is closed. Repeat with more rings and the machine is gone.\n\nThe overflow itself is ancient - it was introduced together with\nTPACKET_V3 in f6fb8f100b80 (\"af-packet: TPACKET_V3 flexible buffer\nimplementation.\"). Its effect prior to f7460d2989fa (\"net:\naf_packet: Use hrtimer to do the retire operation\", v6.18) was not\nas clear-cut, though: the return value was stored into an unsigned\nshort retire_blk_tov, so a negative result was truncated, and a\n0-jiffy delay loop could be programmed as well. Neither is nearly\nas detrimental as the immediate maximum-rate spin the hrtimer\nconversion turned it into.\n\n(Unrelated to CVE-2019-20812 - that one was the ethtool failure path\nreturning 0, which now returns DEFAULT_PRB_RETIRE_TOV.)\n\nReproducer, needs CAP_NET_RAW (a --network host container has it by\ndefault) and a 1 Gbps NIC (QEMU e1000 works):\n\n        int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));\n        bind(fd, ...);\n        int v = TPACKET_V3;\n        setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));\n        struct tpacket_req3 req = {\n                .tp_block_size = 0x10000000,\n                .tp_block_nr = 1,\n                .tp_frame_size = 2048,\n                .tp_frame_nr = 0x10000000 / 2048,\n                .tp_retire_blk_tov = 0,\n        };\n        setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req));\n\nCompute in 64 bits instead. The operands are already bounded by the\nexisting validation, so nothing else changes. If you'd prefer a\ndifferent fix, just say so and I'll respin.","modified":"2026-10-19T14:16:49.170703223Z","published":"2026-10-18T16:17:06Z","upstream":["CVE-2026-98547"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98547"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.157.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-108659.json"}}],"schema_version":"1.9.0"}