Homepage

Integer Overflow or Wraparound Affecting kernel-rt-debug-kvm package, versions *

Severity

 Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.21% (11th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-KERNELRTDEBUGKVM-21268907
  • published20 Oct 2026
  • disclosed18 Oct 2026
Report a new vulnerability Found a mistake?

Introduced: 18 Oct 2026

NewCVE-2026-98547  (opens in a new tab)
CWE-190  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:10 kernel-rt-debug-kvm.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug-kvm package and not the kernel-rt-debug-kvm package as distributed by RHEL. See How to fix? for RHEL:10 relevant fixed versions and status.

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-&gt;interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));
    hrtimer_start(&amp;p1-&gt;retire_blk_timer, p1-&gt;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 &lt; 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, &amp;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, &amp;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.

CVSS Base Scores

version 3.1