An administrator opens Debian's security announcement DSA-6568-1 on a Friday morning in October and scrolls. The references run to 273 CVE identifiers, one after another, each a link to a description written as a kernel commit message. Somewhere in that list sits CVE-2026-98432, and nothing on the page says that this one is different from the other 272.
It is different. The flaw lives in the IPv4 TCP handshake, in the code that turns a half-open connection into a real one, and it has been there, by one analysis, since Linux 4.4. Anyone who can send a SYN to a listening port can reach it, before the application behind that port has seen a single byte. Red Hat rates it critical. Ubuntu rates it high.
The one that mattered
The mechanics fit in a paragraph. When a connection completes, tcp_v4_syn_recv_sock() hands the IP options of the request to the new socket without copying them. Another CPU may at that moment be answering a retransmitted SYN for the same request, reading those options under RCU protection only, and the new socket frees them with a plain kfree() as soon as it dies. One side reads what the other has already returned to the allocator. The fix, published upstream in the middle of October, frees the options after an RCU grace period instead, which the neighbouring code paths already did.
The only exploit known so far needs a Multipath TCP listener on the target, which sounds reassuring until one has a look at the defaults. The kernel documentation gives net.mptcp.enabled the default value 1. Go 1.24 changed its standard library so that "ListenConfig now uses MPTCP by default on systems where it is supported (currently on Linux only)." Every Go service that listens on a port on a recent Linux therefore opens an MPTCP listener without its author having written a line about it. One analysis counted 712 of them on a single developer's machine. Until the patched kernel arrives, the published mitigations take that route away without fixing the race: net.mptcp.enabled=0 for the whole machine, or GODEBUG=multipathtcp=0 for a single Go program.
Why there were 273
In February 2024 the Linux kernel became its own CVE Numbering Authority, and its documentation explains the policy that followed with admirable frankness. Because of the layer the kernel sits in, "almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify."
The reasoning, by and large, holds up: a team that marks every fix cannot be accused of hiding the important ones. The same document then says what the policy costs, and to whom: "the applicability of any specific CVE is up to the user of Linux to determine, it is not up to the CVE assignment team," and users "should be aware that large numbers of assigned CVEs are not relevant for their systems."
So the sorting moved to the reader, which is a tall order on a Friday morning. A distribution collects the fixes and ships them, and the administrator gets a list in which a remote, pre-authentication flaw in TCP and a fix for a driver the server has never loaded look exactly alike. The list is honest, and it is 273 lines long.
From the fix to the machine
The upstream fix landed in the stable kernels between 11 and 18 October. What happened next depended entirely on which distribution the administrator had chosen.
Debian's security team shipped it a day after publication. A Red Hat administrator waited 17 days for the same few lines of code. An Ubuntu administrator, on the morning this was written, is still waiting, with a status of "pending" on every current release. The kernel was fixed once. The fix then travelled to each machine through a separate organisation with its own build and its own calendar, and the administrator's protection was decided the day the distribution was picked.
The same month on FreeBSD
FreeBSD had a remote TCP flaw of its own in October, and it reached administrators by quite another road. FreeBSD-SA-26:70.tcp, announced on 14 October, concerns the RACK TCP stack, a loadable module whose path capacity measurement could be made to overflow a 16-bit counter by a remote peer sending enough ACKs. The advisory is one document. It spends a paragraph each on background and problem, and states the impact in a sentence: a kernel heap write of about 512 KB, possibly a panic.
Then it tells the administrator whether to care: "Systems that have not loaded the tcp_rack.ko kernel module are not affected," followed by the command that answers the question, kldstat -m tcp_rack. The correction went into releng/15.1 at 16:04 UTC the same day, and the update was one command away for anybody running the base system from packages, pkg upgrade -r FreeBSD-base. The project that maintains the kernel wrote the advisory and built the update, from the same tree, on the same day.
The speed comes from the shape of the system: the kernel and the base system around it belong to the same project as the security officer. There is no second organisation between the fix and the machine, so there is no second calendar.
The limit
The same day is the agreed day. FreeBSD publishes an advisory once the correction is ready, as most projects do under coordinated disclosure, and the advisory does not say when the report first arrived. What the administrator gets is the first news and the fix in the same hour.
One tree, fewer kernels to patch. A large distribution maintains its own kernel branches for many years and backports every fix into each of them. Part of the waiting on the other side is that backporting, which a single tree with a short list of supported releases does not need.
Debian kept pace. An administrator who chose Debian was covered within a day, provided someone found item 98432 among the 273 and rebooted.
An impact statement is a judgement. The FreeBSD security team carry the risk of judging a flaw wrongly; the kernel's policy hands that risk to the reader instead.
The bill
The bill for 273 lines goes to the reader. On a Linux server the administrator decides which of them describes a door into the machine, and then waits for whichever organisation builds the kernel, hoping meanwhile that no Go service has opened a listener nobody asked for. On FreeBSD the bill was a single advisory with a command to check and a command to update, issued on a Wednesday.
Two hundred and seventy-three numbers arrived on one day, and only one of them needed anybody to hurry.