Набор инструментов для смягчения последствий CVE-2026-98432

Use-after-free в IPv4 TCP inet_opt/ireq_opt (исправление в upstream e3f33b0a, kfree → kfree_rcu в inet_sock_destruct() + tcp_v4_reqsk_destructor()). Триггер: клиентский SYN, несущий опции IPv4 (ihl > 5) — без опций объект ireq_opt, участвующий в гонке, никогда не выделяется. Заявленный эксплойт для получения root удалённо дополнительно требует MPTCP-листенер.

Файлы

файл	требует root	назначение
`cve-audit.sh`	нет	отчёт только для чтения о подверженности и возможности патчинга
`cve-mitigate.sh`	apply/undo	отбрасывание через nft SYN с опциями IP, опционально отключение MPTCP
`nft-rules.txt`	—	набор правил отдельно (`nft -f nft-rules.txt`)
`cve-detect.sh`	режимы захвата	сенсор tcpdump для формы пакетов эксплойта
`kpatch-el-build.sh`	build/install	проверенный сборщик kpatch/livepatch для семейства EL
`klp-handcraft-build.sh`	build/load	написанный вручную модуль klp для ядер с IBT, где kpatch-build не может работать (EL10)
`patches/CVE-2026-98432.patch`	—	исправление из upstream, готовое для kpatch-build
`tests/run-tests.sh`	нет	тестовый стенд (загрузка набора правил в netns + e2e со сборщиком-заглушкой)

Быстрый старт при инциденте

./cve-audit.sh                                # where do I stand?
./cve-mitigate.sh apply --with-mptcp-off      # closes trigger + claimed root path
./cve-detect.sh count 30                      # anyone probing with IP options?
sudo ./kpatch-el-build.sh --name CVE-2026-98432 \
     --expect inet_sock_destruct,tcp_v4_reqsk_destructor \
     [--sign priv.pem cert.pem] [--install] \
     patches/CVE-2026-98432.patch
# verify: cat /sys/kernel/livepatch/CVE-2026-98432/enabled  -> 1
./cve-mitigate.sh status                      # keep until 100% patched, then:
./cve-mitigate.sh undo

Матрица EL

target	примечания
EL7 (3.10)	не уязвим (код триггера появился в 4.4); сборщик всё равно работает для других патчей
EL7h/EL8 (4.18)	уязвим; kernel-debuginfo предоставляет `/usr/src/debug/kernel-/linux-`; kpatch-build из EPEL
EL9 (5.14)	уязвим; ядро собрано с gcc-toolset — сборщик автоматически подставляет соответствующий `/opt/rh/gcc-toolset-*`
EL10 (6.12)	IBT: kpatch-build 0.9.11 отказывается от ядер с `CONFIG_X86_KERNEL_IBT=y` (dynup/kpatch#1320) — используйте `klp-handcraft-build.sh`; подпись модулей принудительна при Secure Boot/lockdown
CloudLinux 8/9/10	идентификатор дистрибутива отсутствует в списке поддерживаемых kpatch-build, поэтому сборщик всегда явно передаёт `-s/-c/-v`; debuginfo берётся из AlmaLinux/CentOS kernel-debuginfo, соответствующего `rpm -qf /boot/vmlinuz-$(uname -r)`

Для debuginfo на RHEL нужно включить репозитории, например dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms и т. п. на неоплаченных хостах).

Что сборщик проверяет перед тем, как вы что-либо загрузите

CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y в конфигурации работающего ядра.
Целевое ядро == работающее ядро (стена vermagic), присутствуют kernel-devel/debuginfo/vmlinux.
Патч применяется в прямом направлении; если он применяется в обратном направлении, вам сообщают, что ядро уже содержит исправление (kpatch позже завершился бы с ошибкой "no functional changes").
Компилятор совпадает с gcc, которым собиралось ядро (проверка на уровне .comment делегируется kpatch-build; поиск toolset выполняется здесь).
После сборки: vermagic и строгий двусторонний allowlist изменённых функций (--expect) — неожиданный третий изменённый объект является жёстким провалом.
Опционально sign-file с вашей парой ключей + повторная проверка modinfo sig_type; зарегистрируйте сертификат через MOK для Secure Boot.
--install помещает результат в /var/lib/kpatch/$(uname -r)/, загружает через kpatch/insmod, включает kpatch.service для сохранения после перезагрузки.

Runbook для канарейки (сделайте это перед раскаткой на парк)

Канареечная VM с тем же uname -r, что и в парке.
./kpatch-el-build.sh ... --install; убедитесь, что /sys/kernel/livepatch/<name>/enabled == 1.
Гонка-молот: со второй машины запустите флуд hping3 -S -p <port> --tcp-opts ... по слушателю, одновременно переключая net.ipv4.tcp_migrate_req=1 на канарейке; вариант ядра с KASAN и искусственным udelay() внутри ip_options_build() должен воспроизвести UAF без патча и оставаться тихим с ним.
Следите, чтобы uname -r не менялся (livepatch его не повышает), проверяйте kpatch list, dmesg -w на предмет taint и застреваний перехода klp (/sys/kernel/livepatch/<name>/transition должен опуститься до 0).
Раскатывайте на парк; снимайте правило nft через 24–48 ч после 100% покрытия.
В любом случае перезагрузитесь в вендорное ядро при следующем окне — livepatch плохо накладываются друг на друга при обновлениях ядра.

Статус / честность

Harness: все проверки проходят на VM AlmaLinux 10.2 (ядро 6.12.0-211.64.1.el10_2). Реальные наборы правил nft загружаются и перечисляются внутри свежего netns; фильтры pcap компилируются против живого tcpdump; конвейер сборщика прогоняется end-to-end против заглушки kpatch-build с реальным фикстуром .ko и внедрёнными потоками символов.

Проверено вживую на этой виртуальной машине EL10:

klp-handcraft-build.sh --load собрал и включил livepatch: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, переход завершён, sysfs перечисляет inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1; обычный TCP (HTTP 200) не затронут. Неподписанный .ko помечает ядро как tainted; lockdown Secure Boot отказал бы в его загрузке (ВМ работала без подписи).
Настоящий kpatch-build (dynup 0.9.11, собранный из исходников) жёстко падает на EL10 с ошибкой "kernel option CONFIG_X86_KERNEL_IBT not supported" — сборщик теперь выполняет предварительную проверку этого и указывает на ручной маршрут. Реальный запуск kpatch-build с бинарным диффом по-прежнему не проверен на EL8/EL9.
Мера защиты работает вживую: 20 scapy option-SYN по сети были подсчитаны и отброшены правилом guard; 3 обычных SYN прошли; ssh не затронут.
Полевая находка: на EL10 6.12.0-211 сконструированные SYN с IP-опциями попадают в raw-хук nft prerouting (-300), но никогда не достигают хука INPUT (открытый порт, lo и чистый netns — всё воспроизводится; события tracepoint kfree_skb нет, хотя SELinux блокировал perf/kprobes, а tcpdump ничего не захватил, поэтому точная функция сброса не установлена). Поэтому цепочка защиты перехватывает prerouting priority raw, который их видит и отбрасывает; правило знакомого на prerouting priority -310 работает по той же причине. Прогоните happy path один раз на своём канареечном EL-хосте, прежде чем доверять ему в инциденте.

cve-2026-98432

Популярное