CVE-2026-98547

W jądrze Linuksa usunięto następującą lukę:

af_packet: napraw przepełnienie liczb całkowitych w prb_calc_retire_blk_tmo()

prb_calc_retire_blk_tmo() oblicza w 32-bitowej arytmetyce typu int:

mbit = (blk_size_in_bytes * 8) / (1024 * 1024);

Jeśli dobrze czytam walidację, tp_block_size to użytkownik
kontrolowane, a package_set_ring() odrzuca tylko wartości <= 0
jako int lub nie, wyrównane do strony, więc blok 256 MB przechodzi bezpośrednio
(a funkcja alloc_one_pg_vec_page() ma nawet dla niej funkcję zastępczą vzalloc).
0x10000000 * 8 zawija się do INT_MIN, a na karcie sieciowej zgłaszającej 1 Gb/s
(div == 1) funkcja kończy się zwróceniem -2047.

Warunek to właściwie (8 * rozmiar) mod 2^32 >= 2^31 && div == 1,
więc zestaw wyzwalaczy to [256,512), [768,1024), [1280,1536) i
[1792,2048) MiB. Inne rozmiary zawijają się do wartości nieujemnych i szybciej
linki dzielą wartość bez znaku z powrotem poniżej 2^31, dlatego to
nie wybucha każdemu.

Fatalne jest to, co dzieje się później w 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);

Ujemny względny limit czasu wygasa natychmiast. Oddzwonienie
bezwarunkowo zwraca HRTIMER_RESTART, a hrtimer_forward() odwraca się
ujemny interwał w hrtimer_activate:

if (interwał <rozdzielczość_hrtimera)
interwał = rozdzielczość_hrtimera;

Zatem licznik SOFT ponownie uruchamia się z maksymalną częstotliwością przez cały czas, utrzymując się
sk_receive_queue.zablokuj każde przejście. Jeden procesor kręci się w softirq, aż do momentu
gniazdo jest zamknięte. Powtórz tę czynność z większą liczbą pierścieni, a maszyny już nie będzie.

Sam przelew jest starożytny - został wprowadzony razem z
TPACKET_V3 w f6fb8f100b80 („pakiet af: elastyczny bufor TPACKET_V3
wdrożenie.”). Jego efekt przed f7460d2989fa („net:
af_packet: Użyj hrtimera, aby wykonać operację wycofania”, wersja 6.18) nie była
jednak jako jednoznaczne: zwracana wartość została zapisana w unsigned
short retire_blk_tov, więc wynik negatywny został obcięty, oraz a
Można również zaprogramować pętlę opóźnienia 0-jiffy. Żadne nie jest prawie
równie szkodliwe, jak natychmiastowe maksymalne przekręcenie hrtimera
konwersja zamieniła to w.

(Niezwiązane z CVE-2019-20812 – to była ścieżka awarii narzędzia ethtool
zwracając 0, co teraz zwraca DEFAULT_PRB_RETIRE_TOV.)

Replikator, potrzebuje CAP_NET_RAW (posiada go kontener hosta --network
domyślnie) i kartę sieciową 1 Gb/s (działa QEMU e1000):

int fd = gniazdo(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
wiązanie(fd, ...);
int v = TPACKET_V3;
setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));
struktura 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));

Zamiast tego obliczaj w 64 bitach. Operandy są już ograniczone przez
istniejącej walidacji, więc nic innego się nie zmienia. Jeśli wolisz
inna poprawka, po prostu powiedz, a ja odpowiem.