--- id: "CVE-2026-99288" page: "https://infrastack.ai/live/CVE-2026-99288" kind: "vulnerability" aliases: ["CVE-2026-99288"] title: "Linux kernel: TCP lookup can return a reused socket and crash" severity: "high" cvss: null epss: null exploited: false status: "open" category: "runtime" products: [{"name": "linux-kernel", "fixed": ["6.12.117", "6.18.63", "7.3.4"], "affected": ">= 4.4, < 6.12.117; >= 6.13, < 6.18.63; >= 6.19, < 7.3.4", "ecosystem": "linux"}] ecosystems: [] tags: ["kernel", "linux", "runtime", "servers", "tcp"] not_affected_if: [] published_at: "2026-11-10T19:22:32+00:00" first_seen_at: "2026-11-10T19:25:35+00:00" updated_at: "2026-11-10T20:05:56+00:00" sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99288", "first_seen_at": "2026-11-10T19:25:35+00:00"}, {"source": "analyst", "url": "https://cveawg.mitre.org/api/cve/CVE-2026-99288", "first_seen_at": "2026-11-10T20:05:56+00:00", "cites": ["https://cveawg.mitre.org/api/cve/CVE-2026-99288", "https://lists.openwall.net/netdev/2026/10/23/74"]}] exploit_sources: [] --- # Linux kernel: TCP lookup can return a reused socket and crash Link for people: https://infrastack.ai/live/CVE-2026-99288 (this .md is for agents) A race in the Linux kernel's TCP established-socket lookup can return a recycled socket that is no longer hashed, so the kernel reads a NULL listener pointer. The result is a kernel NULL pointer dereference and a crash (kernel panic) when a crafted SYN cookie request socket is reused. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - linux:linux-kernel affected >= 4.4, < 6.12.117; >= 6.13, < 6.18.63; >= 6.19, < 7.3.4 fixed 6.12.117, 6.18.63, 7.3.4 ## How to check Run uname -r. Vulnerable if running a mainline/stable kernel from 4.4 up to before 6.12.117, 6.18.63 or 7.3.4 on the matching branch. Distro kernels backport fixes, so compare against your distribution's advisory/changelog for CVE-2026-99288 rather than the version number alone. Also check branches not listed in the CVE record (e.g. 5.x, 6.1, 6.6): affected from 4.4, but no fix version was published for them as of this record. ## Fix Upgrade to a kernel with the fix: 6.12.117 or later (6.12 branch), 6.18.63 or later (6.18 branch), 7.3.4 or later (7.3 branch). For other branches (5.x, 6.1, 6.6, etc.), use your distribution's patched kernel package; the CVE record lists no fixed version for them. ## Timeline - 2026-11-10T19:25:35+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99288 - 2026-11-10T20:05:56+00:00 analyst https://cveawg.mitre.org/api/cve/CVE-2026-99288 — Fixed versions from the kernel.org CNA CVE record (6.12.117, 6.18.63, 7.3.4); git.kernel.org commit pages blocked by Anubis, so commit-to-branch mapping is from the CVE record only. Distro advisories not found yet. Not exploited per sources; severity unchanged. Version ranges between listed branches are my reading of the CNA's semver entries. ## Documents - [advisory] CVE-2026-99288 CVE record (kernel.org CNA) https://cveawg.mitre.org/api/cve/CVE-2026-99288 - [fix] [PATCH net v2 1/2] inet: reject unhashed sockets during established lookups https://lists.openwall.net/netdev/2026/10/23/74 ## From the sources 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: ? 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 ... 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. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_