Commit 56d82862a0a2 for kernel

commit 56d82862a0a243ac14ba11b6d7b57ddc2d064b95
Author: Dairui Zhang <zhangdairui@gmail.com>
Date:   Wed Sep 23 13:01:01 2026 +0800

    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.

    Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dairui Zhang <zhangdairui@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20260923050101.1510064-1-zhangdairui@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 64b501db660a..7c83e01526ed 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -617,7 +617,7 @@ static int prb_calc_retire_blk_tmo(struct packet_sock *po,
 		return DEFAULT_PRB_RETIRE_TOV;

 	div = ecmd.base.speed / 1000;
-	mbits = (blk_size_in_bytes * 8) / (1024 * 1024);
+	mbits = (u64)blk_size_in_bytes * 8 / (1024 * 1024);

 	if (div)
 		mbits /= div;