CVE-2026-98547: af_packet: fix integer overflow in prb_calc_retire_blk_tmo()
In the Linux kernel, the following vulnerability has been resolved:
afpacket: fix integer overflow in prbcalcretireblktmo()
prbcalcretireblktmo() computes in 32-bit int arithmetic:
mbits = (blksizeinbytes 8) / (1024 1024);
If I'm reading the validation right, tpblocksize is user controlled and packetsetring() only rejects values that are <= 0 as int or not page aligned, so a 256MiB block goes right through (and alloconepgvecpage() even has a vzalloc fallback for it). 0x10000000 8 wraps to INTMIN, and on a NIC reporting 1 Gbps (div == 1) the function ends up returning -2047.
The condition is actually (8 size) mod 2^32 >= 2^31 && 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 initprbbdqc():
p1->intervalktime = mstoktime(prbcalcretireblktmo(...)); hrtimerstart(&p1->retireblktimer, p1->intervalktime, HRTIMERMODERELSOFT);
A negative relative timeout expires immediately. The callback unconditionally returns HRTIMERRESTART, and hrtimerforward() turns the negative interval into hrtimerresolution:
if (interval < hrtimerresolution) interval = hrtimerresolution;
So the SOFT timer re-fires at the maximum rate forever, holding skreceivequeue.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 TPACKETV3 in f6fb8f100b80 ("af-packet: TPACKETV3 flexible buffer implementation."). Its effect prior to f7460d2989fa ("net: afpacket: Use hrtimer to do the retire operation", v6.18) was not as clear-cut, though: the return value was stored into an unsigned short retireblktov, 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 DEFAULTPRBRETIRETOV.)
Reproducer, needs CAPNETRAW (a --network host container has it by default) and a 1 Gbps NIC (QEMU e1000 works):
int fd = socket(AFPACKET, SOCKRAW, htons(ETHPALL)); bind(fd, ...); int v = TPACKETV3; setsockopt(fd, SOLPACKET, PACKETVERSION, &v, sizeof(v)); struct tpacketreq3 req = { .tpblocksize = 0x10000000, .tpblocknr = 1, .tpframesize = 2048, .tpframenr = 0x10000000 / 2048, .tpretireblktov = 0, }; setsockopt(fd, SOLPACKET, PACKETRXRING, &req, 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.