A four-line kernel fix committed October 1 addresses one of the most exposed Linux vulnerabilities in years: CVE-2026-98432, a use-after-free in the IPv4 TCP handshake that lets a remote, unauthenticated attacker leak kernel heap memory, corrupt kernel memory, or execute code as root. The Linux kernel CNA and Red Hat both score it CVSS 3.1 9.8, Critical. The bug has existed since Linux 4.4, meaning virtually every Linux server deployed in the last decade carries it. The mechanism is straightforward. When a server accepts a TCP connection, the kernel tracks the half-open handshake in a request socket. If the connecting peer's IPv4 header carried options, the kernel saves them to echo in replies. The bug: the kernel handed those saved options to the new connection without copying them, then freed the memory while another CPU could still be reading it. The fix changes two plain kfree() calls to kfreercu(), which waits until every reader finishes before freeing. Other code paths already did this correctly. IPv6 connections are not affected. The vulnerability sits in code that runs before any application sees the connection — before authentication, before TLS, before anything. Red Hat's bulletin states a remote unauthenticated attacker "could exploit a race condition during TCP connection request processing to trigger remote code execution." Anthropic, whose researcher Xinyang Ge reported the bug, says its Claude model built a working proof-of-concept exploit achieving remote root on "Linux servers with a multipath TCP listener." The exploit hasn't been published, but the attack surface is enormous: Go programs since version 1.24 enable MPTCP listeners by default on Linux, and the Go Security Team warns "the underlying bug is not specific to MPTCP." Upstream stable kernels shipped fixes between October 11 and 18 across eight release lines from 5.10.272 through 7.3. Debian is fully patched. Amazon Linux is fully patched. Oracle Linux shipped Unbreakable Enterprise Kernel fixes on October 16. But as of 5:15 PM CDT October 31, Ubuntu's tracker lists its kernel as "Vulnerable" on every release, with work-in-progress status on some. Red Hat lists RHEL 8, 9, and 10 as affected with no fix, though it raised severity to Critical on October 30 and says it is "expediting the release of fixes." AlmaLinux has fixed kernels in testing but hasn't moved them to production. The NVD itself lists the CVE as "Received" with no analysis. The distribution lag is the real story. The upstream fix is trivial — two lines changed in two files. But enterprise Linux users don't run upstream kernels. They run distribution kernels with backported patches under their own version numbers, and those patches require the distribution's QA pipeline. Every day that pipeline takes is a day millions of servers sit exposed to a pre-authentication remote code execution bug with a published proof-of-concept path. Container hosts and Kubernetes nodes are equally exposed: containers run on the host kernel, so a new container image changes nothing. Red Hat's bulletin offers an nftables mitigation for systems that can't patch immediately. The practical guidance is blunt: install your distribution's fixed kernel as soon as it ships, then reboot. A kernel update doesn't take effect until the machine boots into it. Check running kernels on container hosts and Kubernetes nodes, not inside containers. For MPTCP exposure specifically, ss -M lists only MPTCP sockets — an empty result means no MPTCP listener, though the underlying bug may not require one. This is a systems resilience failure, not a software complexity failure. The fix was known for a month before most enterprise distributions shipped it. The vulnerability window between upstream fix and downstream availability is the structural weakness, and it's one the Linux ecosystem has never solved at scale.
