CVE-2026-98547

/// Technical description

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_kt

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References