HIGH Introduced in 4.4
inet EstablishedLookup Race
CVE-2026-99288
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
01Description
In the Linux kernel, the following vulnerability has been resolved: inet: reject unhashed sockets during established lookups TCP established ehash lookups are lockless. The socket caches involved use SLAB_TYPESAFE_BY_RCU, so memory can be reused before an RCU reader that retained its old address has finished. After a tuple match, __inet_lookup_established() and __inet6_lookup_established() acquire a reference and repeat the tuple check. They do not check whether the new object is hashed. If the address is reused for a socket with the same tuple, the lookup can acquire a reference to the new object and return it while its nulls node is unhashed. A PoC that drives reuse with a SYN cookie request socket reproduced the crash. The new request socket is unhashed and has a NULL rsk_listener. A lookup that had loaded the address of the old request socket acquired the reference published by tcp_get_cookie_sock() and returned the new object. tcp_v4_rcv() then read sk_state through the NULL listener. The resulting crash was: BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy) ... RIP: 0010:tcp_v4_rcv+0x44e/0x1280 ... R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000 ... CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0 ... Call Trace: <IRQ> ? raw_local_deliver+0xae/0x240 ip_protocol_deliver_rcu+0x2d/0x180 ip_local_deliver_finish+0x84/0x100 ip_sublist_rcv_finish+0x5f/0x70 ip_sublist_rcv+0x12a/0x1d0 ip_list_rcv+0xfd/0x130 __netif_receive_skb_list_core+0x223/0x250 netif_receive_skb_list_internal+0x1d2/0x2c0 ? try_fill_recv+0x39/0x7b0 napi_complete_done+0x74/0x170 virtnet_poll+0x445/0x600 __napi_poll+0x27/0x1e0 net_rx_action+0x2fe/0x3b0 handle_softirqs+0xc2/0x2c0 __irq_exit_rcu+0x74/0xd0 common_interrupt+0x7f/0x90 </IRQ> ... Kernel panic - not syncing: Fatal exception in interrupt After taking a reference, check whether the nulls node is unhashed in both IPv4 and IPv6 established lookups. If it is unhashed or the tuple no longer matches, drop the reference and restart the lookup. Lookups racing with the TIME_WAIT hashdance, or with a request being replaced by its child, now restart and find the new socket instead of returning the old one. Request sockets that were never inserted into ehash can have a nonzero refcount, and a stale lookup can hold a transient reference. Therefore, when SYN cookie, Fast Open, and request migration paths fail after setting a nonzero refcount, release the references held by those paths with reqsk_put() instead of freeing the request directly.
02KernelScan AI Analysis
Risk summary
A race in the lockless TCP connection lookup can return a socket that is not yet registered. The reporter's proof of concept (not public) turns this into a kernel panic in the packet receive path, using a SYN-cookie request socket. That is a denial of service; whether a purely remote attacker can win the race has not been demonstrated, and a local user can drive both sides over loopback. No privilege escalation or memory corruption primitive has been shown. Fixed in 6.12.117, 6.18.63 and 7.3.4 (first patch only); 5.10, 5.15, 6.1 and 6.6 are not fixed yet. On arm64 and other weakly ordered CPUs a second patch is also needed.
On the KernelScan blog
Vulnerability analysis
TCP established-connection lookups (__inet_lookup_established / __inet6_lookup_established) take no locks, and TCP sockets live in SLAB_TYPESAFE_BY_RCU caches, so a closed socket's memory can be reused for a new socket while a lookup still holds the old address. After taking a reference, the lookup re-checked the connection tuple but not whether the socket is registered in the hash table. If the memory comes back as an unregistered socket with the same tuple, the lookup returns it. In the published crash this is a SYN-cookie request socket with a NULL listener, and tcp_v4_rcv() dereferences that NULL pointer, panicking the kernel in interrupt context. The fix 4e2b3ef19e0e adds the missing unhashed check and makes the SYN-cookie, Fast Open and request-migration failure paths drop references with reqsk_put() instead of freeing directly. A companion patch, 5b5d8f351dd9, adds acquire/release ordering; without it the new check is not ordered on weakly ordered CPUs (arm64, 32-bit ARM, RISC-V, PowerPC, MIPS). The demonstrated route needs SYN cookies (CONFIG_SYN_COOKIES, default sysctl tcp_syncookies=1, used when a listener's SYN queue overflows), but the lookup flaw itself is in core TCP, so a build without SYN cookies should not be marked not affected on that basis alone. A remote client controls its own packets and can push a listener into SYN-cookie mode; winning the race remotely has not been shown. A full-socket use-after-free variant was only reproduced on a kernel instrumented with artificial delays, was disputed by the TCP maintainer, and is not part of the final fix description. Affected: 4.4 up to 6.12.116, 6.18.62 and 7.3.3, all 5.10/5.15/6.1/6.6 releases as of 11 November 2026, and all end-of-life series since 4.4. The first patch is queued for 5.10, 5.15, 6.1 and 6.6; the second is queued for 6.12, 6.18 and 7.3 and needs an adapted backport for 5.10 to 6.6.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 4.4 | 6.12.117 | d69100340b4c |
| 6.18 | 4.4 | 6.18.63 | 8e5172cbd227 |
| 7.3 | 4.4 | 7.3.4 | eb8a2d156f2c |
| mainline | 4.4 | 7.4-rc2 | 4e2b3ef19e0e |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Affected — no CIP fix yet (latest 6.12.114-cip34) |
| cip/6.1 | Affected — no CIP fix yet (latest 6.1.190-cip62) |
| cip/6.1-rt | Affected — no CIP fix yet (latest 6.1.189-cip61-rt32) |
| cip/5.10 | Affected — no CIP fix yet (latest 5.10.272-cip79) |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.272-cip79-rt35) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |