CVSS 8.1, Network-Rated, No Long-Term Fix: Is the Linux TCP Use-After-Free CVE-2026-99270 Reachable in Your Product?

The facts

How the bug works

Between the SYN and the final ACK of a handshake, the kernel keeps a small request socket and a timer that retransmits the SYN+ACK. With SO_REUSEPORT, several listening sockets can share one port. When one of them is closed, its pending handshakes would normally be dropped. Listener migration, added in 5.14, lets the kernel move them to another listener in the group instead. One of the places where that happens is the retransmit timer: reqsk_timer_handler() sees that its listener is gone, clones the request socket for a live listener (nreq), arms the clone’s timer, and swaps the clone into the connection hash table.

If the swap fails, because another CPU processed the client’s ACK or a reset for the original request in the meantime, the handler frees the clone right away. Before freeing it has to cancel the clone’s timer, and that is the line that was wrong:

 		if (!inet_ehash_insert(req_to_sk(nreq), req_to_sk(oreq), NULL)) {
 			/* delete timer */
-			__inet_csk_reqsk_queue_drop(sk_listener, nreq, true);
+			__inet_csk_reqsk_queue_drop(sk_listener, nreq, false);
 			goto no_ownership;	/* frees nreq */
 		}

The last argument says “we are running inside this socket’s own timer, do not wait for it”. That is true for the original request, not for the clone. With true, the clone’s timer is never cancelled, the clone is freed, and when the timer fires later it runs on freed memory.

The gate is a sysctl, not a Kconfig option

Every kernel with networking builds this code; there is no CONFIG_* symbol that removes it. What decides whether the vulnerable branch can run is whether listener migration is switched on:

# Off by default. Must be 1 in the network namespace that owns the listener ...
sysctl net.ipv4.tcp_migrate_req          # net.ipv4.tcp_migrate_req = 0

# ... or a reuseport BPF program attached with the migrate attach type
bpftool prog show | grep -i sk_reuseport

On top of that, the server application has to use SO_REUSEPORT with at least two listeners on the same port, and close one of them while handshakes are still pending. That is the zero-downtime-restart pattern that the feature was built for. A product whose services do not use SO_REUSEPORT, or that never enables migration, never runs the vulnerable branch.

Two attackers, two different answers

There is no module to autoload here: TCP is built in, and nothing about this bug changes when someone plugs in a device. The useful split is between an attacker on the network and an attacker who already runs code on the box.

The setting in your root network namespace does not protect against the local case: the attacker’s own namespace has its own copy of tcp_migrate_req, and root inside a user namespace may change it. For products with untrusted local code (containers, apps, multi-tenant hosts), the user-namespace policy is the real gate.

Is it a local root risk? Compared with exploited bugs of the same class

Race-condition use-after-frees are a recurring source of this year’s public Linux root exploits. To judge this one, we compared it with the race-condition UAFs in our exploit database that have a working public exploit, plus the earlier bug in the same function. The columns are the properties that decide how hard such a bug is to turn into root: where the freed memory lives, and what makes the kernel use it again. The score is our estimate of the exploit difficulty, from 1 (easy) to 5 (hard).

On access, the field is level: the two kernelCTF network exploits ran inside an unprivileged user namespace, Bad Epoll needs no special privileges, and this bug needs an unprivileged user namespace with listener migration switched on inside it. CVE-2024-50154 was reported through a privileged BPF tracing program.

Two properties put this bug at the hard end of the class. First, the freed request socket sits in a type-stable cache: freed slots go only to other request sockets, so the attacker has to free whole slab pages and win them back as different memory. That “cross-cache” step is what Bad Epoll and the TLS exploit had to solve as well. Second, in every exploited bug in the table the attacker chooses the moment the kernel touches the freed memory, with a syscall or a packet. Here the stale retransmit timer fires on the kernel’s own schedule, so the attacker has to have the memory in place before it fires rather than trigger the use when ready.

The timeline NVD won’t show yet

Which kernels really have it

The CVE record marks everything from 4.1.11 and 4.2 onward as affected, because the fix’s Fixes: tag points at a 2015 commit. Reading the code gives a narrower range. Kernels before 5.14 have no migration code at all. From 5.14 until the October 2024 change, the clone’s timer was cancelled with a timer_pending() check, and since the handler had just armed that timer on the same CPU, the check always succeeded. The bug appears when e8c526f2bdf1 replaced that check with the true/false argument. The second patch in the same series supports this: it fixes the same migration-failure path and carries Fixes: e8c526f2bdf1. This range is our own analysis; expect scanners that follow the CVE record to flag older kernels too.

Was the risk visible at merge?

The commit message says “UAF” in the subject, so it was not a silent fix. But it carries no Cc: stable tag, which is the usual signal for the stable maintainers to pick a patch up. Six months later, 5.15, 6.1, 6.6, 6.12 and 6.18 still ship the bug, and 7.0 reached end of life without the fix. The day after the CVE was published, the fix was queued for all five long-term branches, so the gap should close with their next releases. 7.1 and later releases have it. The fix is a one-line change and applies to the long-term branches without conflicts, so product teams that cannot wait can carry it themselves.

What the distributions say

The distributions follow the long-term branches, so their kernels have the same gap. Their own ratings are notably lower than the CNA’s 8.1 (status of their trackers on 4 November 2026):

SUSE scores it as a local attack and Red Hat as a denial of service, which matches the threat-model split above more closely than the CNA’s network score.

What your tools will show

NVD has not analysed the CVE yet, so there is no NVD score and no CPE version range. Dependency-Track and other NVD-fed scanners will either show it unscored or not match it to your kernel until that analysis lands. When it does, the range will likely follow the CVE record and start at 4.1.11.

30-second checklist

1. Is your kernel version in the affected range? Before 5.14, 5.15 before .170, 6.1 before .115, 6.6 before .59, 6.7–6.10, 6.11 before .6, or 7.1 and later: not_affected, justification code_not_present. Otherwise continue.
2. Can untrusted local code create user namespaces? If your product runs third-party apps, containers or other users’ code, and unprivileged user namespaces are allowed, treat it as affected: carry the fix, or disable unprivileged user namespaces (user.max_user_namespaces=0, or your distribution’s switch). If there is no untrusted local code, or user namespaces are not available to it, continue.
3. Does any listening service enable migration? Check net.ipv4.tcp_migrate_req in every network namespace that has listeners, and whether any service attaches a reuseport BPF program. If migration is off everywhere: not_affected, justification requires_configuration. If it is on, a remote client can reach the bug while that service restarts: patch, or turn migration off until you can.

The score is not the answer

An 8.1 network score on a TCP bug sounds like every product is exposed. For most of them the honest answer is that the vulnerable branch never runs, and for the rest it depends on who can run code on the box. Upload your .config to KernelScan and every kernel CVE is checked against your exact kernel version, the long-term backports and the options your product builds. On paid plans, the security factors you declare for a product, such as whether it runs untrusted code, feed into the assessment of each CVE.