Kit de mitigación de CVE-2026-98432

Use-after-free de IPv4 TCP inet_opt/ireq_opt (corrección upstream e3f33b0a, kfree → kfree_rcu en inet_sock_destruct() + tcp_v4_reqsk_destructor()). Disparador: SYN de cliente que transporta opciones IPv4 (ihl > 5) — sin opciones el objeto en carrera ireq_opt nunca se asigna. El supuesto exploit de root remoto requiere además un listener MPTCP.

Archivos

archivo	requiere root	propósito
`cve-audit.sh`	no	informe de exposición y parcheabilidad de solo lectura
`cve-mitigate.sh`	aplicar/deshacer	descarte con nft de SYNs con opciones IP, desactivación opcional de MPTCP
`nft-rules.txt`	—	el conjunto de reglas independiente (`nft -f nft-rules.txt`)
`cve-detect.sh`	modos de captura	sensor tcpdump para la forma de paquete del exploit
`kpatch-el-build.sh`	compilar/instalar	constructor validado de kpatch/livepatch para la familia EL
`klp-handcraft-build.sh`	compilar/cargar	módulo klp escrito a mano para kernels con IBT donde kpatch-build no puede ejecutarse (EL10)
`patches/CVE-2026-98432.patch`	—	corrección upstream, lista para kpatch-build
`tests/run-tests.sh`	no	arnés de pruebas (carga del conjunto de reglas en netns + e2e del constructor con stubs)

Inicio rápido ante 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 de EL

objetivo	notas
EL7 (3.10)	no vulnerable (el código del disparador llegó en 4.4); el builder sigue funcionando para otros parches
EL7h/EL8 (4.18)	vulnerable; kernel-debuginfo proporciona `/usr/src/debug/kernel-/linux-`; kpatch-build desde EPEL
EL9 (5.14)	vulnerable; kernel compilado con gcc-toolset — el builder antepone automáticamente el `/opt/rh/gcc-toolset-*` correspondiente
EL10 (6.12)	IBT: kpatch-build 0.9.11 rechaza kernels con `CONFIG_X86_KERNEL_IBT=y` (dynup/kpatch#1320) — use `klp-handcraft-build.sh`; la firma de módulos se aplica bajo Secure Boot/lockdown
CloudLinux 8/9/10	el id de la distro no está en la lista de soporte de kpatch-build, por lo que el builder siempre pasa `-s/-c/-v` explícitamente; el debuginfo proviene del kernel-debuginfo de AlmaLinux/CentOS que coincide con `rpm -qf /boot/vmlinuz-$(uname -r)`

El debuginfo en RHEL requiere repositorios habilitados, p. ej. dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms etc. en hosts sin facturación).

Qué valida el builder antes de que cargues nada

CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y en la configuración en ejecución.
Kernel objetivo == kernel en ejecución (barrera de vermagic), kernel-devel/debuginfo/vmlinux presentes.
El parche se aplica hacia adelante; si se aplica en reversa se te indica que el kernel ya contiene la corrección (kpatch moriría más tarde con "no functional changes").
El compilador coincide con el gcc de compilación del kernel (la comprobación a nivel de .comment se delega a kpatch-build; la búsqueda del toolset se hace aquí).
Tras la compilación: vermagic, y una lista de permitidos bidireccional estricta de funciones modificadas (--expect) — un tercer objeto de cambio inesperado es un fallo duro.
sign-file opcional con tu par de claves + reverificación de modinfo sig_type; inscribe el certificado vía MOK para Secure Boot.
--install lo coloca en /var/lib/kpatch/$(uname -r)/, lo carga vía kpatch/insmod, habilita kpatch.service para persistencia tras reinicio.

Runbook de canario (haz esto antes del despliegue en flota)

VM canario, mismo uname -r que la flota.
./kpatch-el-build.sh ... --install; confirma /sys/kernel/livepatch/<name>/enabled == 1.
Martilleo de carrera: desde una segunda máquina, inundación con hping3 -S -p <port> --tcp-opts ... contra un listener mientras alternas net.ipv4.tcp_migrate_req=1 en el canario; una variante de kernel con KASAN y un udelay() artificial dentro de ip_options_build() debería reproducir el UAF sin el parche y mantenerse silenciosa con él.
Vigila que uname -r no cambie (livepatch no lo incrementa), kpatch list, dmesg -w en busca de taint y bloqueos en la transición de klp (/sys/kernel/livepatch/<name>/transition debe drenarse a 0).
Despliega en la flota; retira la regla de nft 24–48 h después de la cobertura del 100%.
Reinicia al kernel del proveedor en la siguiente ventana de todos modos — los livepatches se apilan mal entre actualizaciones de kernel.

Estado / honestidad

Arnés: todas las comprobaciones pasan en una VM AlmaLinux 10.2 (kernel 6.12.0-211.64.1.el10_2). Se cargan y listan conjuntos de reglas nft reales dentro de un netns nuevo; filtros pcap compilados contra tcpdump en vivo; pipeline del builder ejercitado de extremo a extremo contra un kpatch-build simulado con un fixture .ko real y feeds de símbolos inyectados.

Verificado en vivo en esa VM EL10:

klp-handcraft-build.sh --load compiló y habilitó un livepatch: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, transición drenada, sysfs lista inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1; TCP normal (HTTP 200) no afectado. El .ko sin firmar marca el kernel con taint; el bloqueo de Secure Boot lo rechazaría (la VM se ejecutó sin firma).
El kpatch-build real (dynup 0.9.11, compilado desde el código fuente) falla de forma contundente en EL10 con "kernel option CONFIG_X86_KERNEL_IBT not supported" — el builder ahora hace una verificación previa de esto y señala la ruta artesanal. Una ejecución real de kpatch-build con diff binario sigue sin probarse en EL8/EL9.
Mitigación en vivo: 20 SYN con opciones de scapy enviados por la red fueron contados y descartados por la regla de guardia; 3 SYN simples pasaron; ssh no se vio afectado.
Hallazgo de campo: en EL10 6.12.0-211, los SYN manipulados con opciones IP alcanzan el hook raw de nft prerouting (-300) pero nunca llegan al hook INPUT (puerto abierto, lo y netns limpio lo reproducen; sin evento del tracepoint kfree_skb, aunque SELinux bloqueó perf/kprobes y tcpdump no capturó nada, por lo que la función exacta de descarte queda sin resolver). Por lo tanto, la cadena de mitigación engancha prerouting priority raw, que los observa y descarta; la regla de un amigo en prerouting priority -310 funciona por la misma razón. Ejecuta la ruta feliz una vez en tu canario EL antes de confiar en ella en un incidente.

cve-2026-98432

Más Populares