googlesky/cve-2026-98432Prueba de concepto verificada con KASAN que reproduce CVE-2026-98432, un use-after-free en inet_opt/ireq_opt de IPv4 TCP del kernel de Linux, con un arnés de carrera entre CPU y un control con kernel corregido.
Vulnerabilidad de uso después de liberación (use-after-free) en inet_opt/ireq_opt de TCP IPv4 del kernel de Linux (CVSS 9.8).
Un SYN con opciones de cabecera IPv4 guarda sus opciones en el socket de la petición.
Cuando el handshake se completa, tcp_v4_syn_recv_sock() entrega el mismo búfer
al socket hijo por puntero, sin copia. Un SYN retransmitido en otra CPU
lo lee en tcp_v4_send_synack()/inet_csk_route_req() mientras el hijo ya
ha desaparecido (inet_sock_destruct() lo liberó con un simple kfree(), los sockets
hijo no tienen SOCK_RCU_FREE). La corrección son dos llamadas a kfree_rcu(), incluidas en
6.6.159 y versiones similares. Vulnerable desde 4.4.
El laboratorio arranca un kernel invitado para que el kernel anfitrión parcheado nunca sea el objetivo:
make image
make kernel-amp kernel-fixed-amp
make rootfs
make test-det-vuln # KASAN: slab-use-after-free in inet_csk_route_req
make test-det-fixed # same attack, clean
phase-det es la reproducción entre CPUs: inundador de dup-SYN fijado a la CPU1 (creación del socket
de petición + su temporizador), ACKs finales en la CPU0 (creación del hijo), accept+close del servidor en la CPU3 (destrucción del hijo). RPS desactivado, netns del atacante/objetivo
sobre un par veth, los paquetes salen como tramas Ethernet en crudo para que el propio kernel del atacante
nunca corte el handshake con un RST. Los kernels -amp añaden un retardo de 5ms
dentro de inet_csk_route_req entre tomar ireq_opt y desreferenciarlo
(inyección de retardo al estilo KCSAN, usada para reproducibilidad solo en estos kernels
de reproducción, claramente marcada en el código fuente).
poc/poc.c también tiene las variantes timerace, race, migrate y mptcp.
evidence/REPRODUCED-UAF-first-splat.txt — 12 splats en una ejecución, el primero:
[ 9.076253] BUG: KASAN: slab-use-after-free in inet_csk_route_req+0x94/0x370
[ 9.076586] Read of size 1 at addr ffff888002ddaa41 by task poc/85
...
tcp_v4_send_synack+0x212/0x240
tcp_rtx_synack+0xd5/0x280
inet_rtx_syn_ack+0x38/0x60
tcp_check_req+0xb8e/0xde0
tcp_v4_rcv+0x1131/0x15e0
...
Allocated by task 79: tcp_v4_route_req+0x116/0x1b0 (options saved on the SYN)
Freed by task 80: inet_sock_destruct+0x2cd/0x380 (child close(), plain kfree)
evidence/VERIFIED-fixed-kernel-clean.log — el mismo ataque sobre el kernel con
las dos llamadas a kfree_rcu() aplicadas: cero informes.
Si aún no puedes parchear, descarta en prerouting los paquetes TCP que lleven opciones IPv4
(ip protocol tcp ip hdrlength > 5 drop), y establece
net.ipv4.tcp_migrate_req=0 para la variante de migración. La solución real es la
actualización del kernel.