CVE-2026-98432 in Linux
Zusammenfassung
von VulDB • 15.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ipv4: inet_opt und ireq_opt nach einer RCU-Grace-Periode freigeben
tcp_v4_syn_recv_sock() überträgt den Besitz von ireq->ireq_opt an das Kind-Socket (newinet->inet_opt), ohne es zu kopieren.
Eine andere CPU kann gleichzeitig ein erneut gesendetes SYN für dasselbe Request-Socket verarbeiten und ein SYNACK aus tcp_check_req() senden. tcp_v4_send_synack() und inet_csk_route_req() lesen ireq->ireq_opt nur unter rcu_read_lock(), und ip_build_and_send_pkt() sowie ip_options_build() lesen opt->optlen zweimal.
Beachten Sie, dass der SYNACK-Timer selbst kein Problem darstellt: Er hält eine Referenz auf sein Request-Socket, und inet_csk_reqsk_queue_drop() ruft timer_delete_sync() auf, bevor das Kind-Socket freigegeben werden kann.
Seit dem Commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") werden Request-Sockets ohne Halten des Listener-Locks verarbeitet, sodass nichts verhindert, dass das Kind-Socket freigegeben wird, während das SYNACK noch erstellt wird. TCP-Kind-Sockets verfügen nicht über SOCK_RCU_FREE, und inet_sock_destruct() gibt inet_opt mit einem einfachen kfree() frei, was zu einer Use-After-Free-Fehler in ip_options_build() führt.
Ein ähnliches Problem besteht bei der Migration von Request-Sockets (net.ipv4.tcp_migrate_req=1 oder ein BPF_SK_REUSEPORT_SELECT_OR_MIGRATE-Programm). reqsk_timer_handler() klont das Request-Socket mit inet_reqsk_clone(), sodass das alte Request-Socket und sein Klon denselben ireq_opt teilen, dann löscht reqsk_migrate_reset() den Zeiger im alten. Eine andere CPU, die eine Referenz auf das alte Request-Socket hält, kann diese Optionen noch verwenden (ein SYNACK senden oder ein Kind in tcp_v4_syn_recv_sock() erstellen), wenn der Klon freigegeben wird, und tcp_v4_reqsk_destructor() verwendet ebenfalls ein einfaches kfree().
Leser verwenden bereits RCU, und andere Pfade zum Ersetzen von inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) verwenden bereits kfree_rcu(). Verwenden Sie auch in inet_sock_destruct() und tcp_v4_reqsk_destructor() kfree_rcu().
IPv6 ist vom ersten Problem nicht betroffen, da tcp_v6_syn_recv_sock() die Optionen dupliziert. tcp_v6_reqsk_destructor() hat das gleiche Migrationsproblem mit ipv6_opt, das nur von CALIPSO festgelegt wird. Dies wird in einem separaten Patch behandelt werden.
VulDB is the best source for vulnerability data and more expert information about this specific topic.