googlesky/cve-2026-98432KASAN-verifizierter Proof-of-Concept zur Reproduktion von CVE-2026-98432, einem Use-after-free im Linux-Kernel-IPv4-TCP-Code inet_opt/ireq_opt, mit einer Cross-CPU-Race-Harness und einer Kontrolle mit gepatchtem Kernel.
Linux-Kernel-IPv4-TCP-inet_opt/ireq_opt-Use-after-Free (CVSS 9.8).
Ein SYN mit IPv4-Header-Optionen speichert seine Optionen im Request-Socket.
Wenn der Handshake abgeschlossen ist, übergibt tcp_v4_syn_recv_sock() denselben Puffer
per Zeiger an das Child-Socket, ohne Kopie. Ein erneut übertragener SYN auf einer anderen CPU
liest ihn in tcp_v4_send_synack()/inet_csk_route_req(), während das Child
bereits weg ist (inet_sock_destruct() hat ihn mit einfachem kfree() freigegeben, Child-
Sockets haben kein SOCK_RCU_FREE). Die Behebung besteht aus zwei kfree_rcu()-Aufrufen, eingeflossen in
6.6.159 und verwandte Versionen. Anfällig seit 4.4.
Das Labor bootet einen Gast-Kernel, damit der gepatchte Host-Kernel niemals das Ziel ist:
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 # gleicher Angriff, sauber
phase-det ist die Cross-CPU-Reproduktion: Dup-SYN-Flooder an CPU1 gebunden (Erstellung des Request-
Sockets + dessen Timer), finale ACKs auf CPU0 (Erstellung des Child), Server-
accept+close auf CPU3 (Zerstörung des Child). RPS aus, Angreifer-/Ziel-netns
über ein veth-Paar, Pakete gehen als rohe Ethernet-Frames raus, damit der Angreifer
mit seinem eigenen Kernel den Handshake niemals per RST abbricht. Die -amp-Kernel fügen eine 5ms-Verzögerung
innerhalb von inet_csk_route_req zwischen dem Nehmen von ireq_opt und dessen Dereferenzierung hinzu
(KCSAN-artige Verzögerungsinjektion, nur zur Reproduzierbarkeit in diesen Reproduktions-
Kerneln verwendet, im Quellcode klar gekennzeichnet).
poc/poc.c hat außerdem die Varianten timerace, race, migrate und mptcp.
evidence/REPRODUCED-UAF-first-splat.txt — 12 Splats in einem Lauf, der erste:
[ 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 — derselbe Angriff auf dem Kernel mit
den beiden angewendeten kfree_rcu()-Aufrufen: null Meldungen.
Wenn du noch nicht patchen kannst, verwirf TCP-Pakete mit IPv4-Optionen beim Prerouting
(ip protocol tcp ip hdrlength > 5 drop) und setze
net.ipv4.tcp_migrate_req=0 für die Migrationsvariante. Die eigentliche Behebung ist das
Kernel-Update.