Kit de mitigação CVE-2026-98432

IPv4 TCP inet_opt/ireq_opt use-after-free (correção upstream e3f33b0a, kfree → kfree_rcu em inet_sock_destruct() + tcp_v4_reqsk_destructor()). Gatilho: SYN do cliente transportando opções IPv4 (ihl > 5) — sem opções o objeto disputado ireq_opt nunca é alocado. O alegado exploit de root remoto requer adicionalmente um listener MPTCP.

Arquivos

arquivo	requer root	finalidade
`cve-audit.sh`	não	relatório somente leitura de exposição + possibilidade de correção
`cve-mitigate.sh`	aplicar/desfazer	descarte via nft de SYNs com opções IP, desativação opcional de MPTCP
`nft-rules.txt`	—	o conjunto de regras autônomo (`nft -f nft-rules.txt`)
`cve-detect.sh`	modos de captura	sensor tcpdump para o formato de pacote do exploit
`kpatch-el-build.sh`	compilar/instalar	construtor validado de kpatch/livepatch para a família EL
`klp-handcraft-build.sh`	compilar/carregar	módulo klp escrito manualmente para kernels IBT onde o kpatch-build não consegue executar (EL10)
`patches/CVE-2026-98432.patch`	—	correção upstream, pronta para kpatch-build
`tests/run-tests.sh`	não	harness (carregamento de conjunto de regras em netns + e2e de construtor com stub)

Início rápido para incidentes

./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

Matriz EL

alvo	observações
EL7 (3.10)	não vulnerável (o código do gatilho chegou na 4.4); o builder ainda funciona para outros patches
EL7h/EL8 (4.18)	vulnerável; kernel-debuginfo fornece `/usr/src/debug/kernel-/linux-`; kpatch-build do EPEL
EL9 (5.14)	vulnerável; kernel compilado com gcc-toolset — o builder prefixa automaticamente o `/opt/rh/gcc-toolset-*` correspondente
EL10 (6.12)	IBT: kpatch-build 0.9.11 recusa kernels com `CONFIG_X86_KERNEL_IBT=y` (dynup/kpatch#1320) — use `klp-handcraft-build.sh`; assinatura de módulos imposta sob Secure Boot/lockdown
CloudLinux 8/9/10	id da distro não está na lista de suporte do kpatch-build, por isso o builder sempre passa `-s/-c/-v` explicitamente; o debuginfo vem do kernel-debuginfo do AlmaLinux/CentOS correspondente a `rpm -qf /boot/vmlinuz-$(uname -r)`

O debuginfo no RHEL exige repositórios habilitados, por exemplo dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms etc. em hosts não faturados).

O que o builder valida antes de você carregar qualquer coisa

CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y na configuração em execução.
Kernel alvo == kernel em execução (barreira do vermagic), kernel-devel/debuginfo/vmlinux presentes.
O patch aplica-se no sentido direto; se aplicar em reverso, você é informado de que o kernel já contém a correção (o kpatch morreria depois com "no functional changes").
O compilador corresponde ao gcc de build do kernel (verificação ao nível de .comment delegada ao kpatch-build; a busca do toolset é feita aqui).
Pós-build: vermagic, e uma allowlist bidirecional estrita de funções alteradas (--expect) — um terceiro objeto de alteração inesperado é falha dura.
sign-file opcional com seu par de chaves + nova verificação de modinfo sig_type; registre o certificado via MOK para Secure Boot.
--install coloca em /var/lib/kpatch/$(uname -r)/, carrega via kpatch/insmod, habilita kpatch.service para persistência após reboot.

Runbook de canário (faça isto antes do rollout para a frota)

VM canário, mesmo uname -r da frota.
./kpatch-el-build.sh ... --install; confirme /sys/kernel/livepatch/<name>/enabled == 1.
Martelamento de corrida: de uma segunda máquina, flood com hping3 -S -p <port> --tcp-opts ... contra um listener enquanto alterna net.ipv4.tcp_migrate_req=1 no canário; uma variante do kernel com KASAN e um udelay() artificial dentro de ip_options_build() deve reproduzir o UAF sem o patch e permanecer silenciosa com ele.
Verifique que uname -r permanece intacto (o livepatch não o incrementa), kpatch list, dmesg -w para taint e travamentos na transição klp (/sys/kernel/livepatch/<name>/transition deve drenar para 0).
Faça o rollout da frota; remova a regra nft 24–48h após 100% de cobertura.
Reinicie no kernel do fornecedor na próxima janela de qualquer forma — livepatches se empilham mal entre atualizações de kernel.

Status / honestidade

Harness: todas as verificações passam em uma VM AlmaLinux 10.2 (kernel 6.12.0-211.64.1.el10_2). Rulesets nft reais são carregados e listados dentro de um netns novo; filtros pcap compilados contra tcpdump em execução; pipeline do builder exercitado de ponta a ponta contra um kpatch-build simulado com um fixture .ko real e feeds de símbolos injetados.

Verificado ao vivo naquela VM EL10:

klp-handcraft-build.sh --load compilou e ativou um livepatch: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, transição concluída, sysfs lista inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1; TCP normal (HTTP 200) não afetado. O .ko não assinado contamina o kernel; o lockdown do Secure Boot o recusaria (a VM rodou sem assinatura).
O kpatch-build real (dynup 0.9.11, compilado a partir do código-fonte) falha de forma definitiva no EL10 com "kernel option CONFIG_X86_KERNEL_IBT not supported" — o builder agora faz uma verificação prévia disso e aponta para a rota artesanal. Uma execução real de kpatch-build com diff binário permanece não exercitada no EL8/EL9.
Mitigação ao vivo: 20 SYNs com opções via scapy na rede foram contados e descartados pela regra de guarda; 3 SYNs simples passaram; ssh não afetado.
Achado de campo: no EL10 6.12.0-211, SYNs forjados com opções IP atingem o hook raw prerouting do nft (-300), mas nunca chegam ao hook INPUT (porta aberta, lo e netns limpo todos reproduzem; nenhum evento de tracepoint kfree_skb, embora o SELinux tenha bloqueado perf/kprobes e o tcpdump não tenha capturado nada, então a função exata de descarte permanece não resolvida). A cadeia de mitigação, portanto, faz hook em prerouting priority raw, que os observa e descarta; a regra de um amigo em prerouting priority -310 funciona pelo mesmo motivo. Execute o caminho feliz uma vez no seu canário EL antes de confiar nele em um incidente.

cve-2026-98432

Mais Populares