PT-2026-116766 · Linux · Linux
CVE-2026-98547
·
Publicado
2026-10-18
·
Atualizado
2026-10-18
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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 <= 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 >= 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 init prb bdqc():
p1->interval ktime = ms to ktime(prb calc retire blk tmo(...));
hrtimer start(&p1->retire blk timer, p1->interval 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 < 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, &v, 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, &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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux