CVE-2026-98371 in Linux
Сводка
по VulDB • 06.10.2026
В ядре Linux была устранена следующая уязвимость:
xfrm: iptfs: исправление паники при сборке фрагментированных пакетов (runt reassembly panic) из-за слишком малого значения tot_len внутреннего пакета
Когда начало внутреннего пакета разделяется между двумя внешними пакетами таким образом, что в конец первого попадает менее 4 байт, функция `__input_process_payload()` сохраняет эти байты как «обрывок» (runt) и пропускает проверку значений iplen/iphlen, которая выполняется для пакетов, обрабатываемых на месте. Когда поступает продолжение пакета, функция `iptfs_reassem_cont()` требует только того, чтобы объявленная длина внутреннего пакета была больше или равна `sizeof(ra_runt)` (6 байт), прежде чем выделять skb для сборки с этой управляемой злоумышленником длиной.
Однако `__iptfs_iphlen()` всегда возвращает фиксированный минимальный размер заголовка IP-пакета (20 байт для IPv4, 40 байт для IPv6), поэтому при значении tot_len внутреннего пакета IPv4 в диапазоне [6, 19] операция копирования завершения заголовка выходит за пределы объявленной длины пакета, а последующее вычисление `ipremain -= copylen` приводит к переполнению со знаком (underflow) до значения ~4 ГБ. Это оставляет длину копии полезной нагрузки ограниченной только значением blkoff (до 64 КБ). Во время выполнения проверка tailroom в функции `skb_put()` преобразует это состояние в вызов `skb_over_panic()`, то есть приводит к панике ядра без привилегий (DoS), которая может быть достигнута локально через namespaces пользователей и сетей (userns+netns) с использованием SA IPTFS, а также удаленно против шлюзов VPN IPTFS при условии линейности расшифрованного внешнего skb (например, в случаях захвата пакетов через AF_PACKET или доставки через tun/tap).
Для согласования пути обработки «обрывков» с обычным путем требуется, чтобы объявленная длина внутреннего пакета покрывала как минимум размер заголовка IP. Это также включает предыдущую проверку `>= sizeof(ra_runt)`, поскольку минимальный размер заголовка IP всегда больше размера буфера для «обрывков».
Эта проблема была обнаружена динамическим фаззером ядра autokbug в лаборатории Tencent Yunding Lab.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.