Closed on our network on 29 October
29 October, 23:38 UTC. Shieldify's edge started dropping every TCP packet that carries IPv4 options as it arrives on its network interface, before the kernel's TCP code sees it. The attack cannot work without those options, and no browser or operating system puts them on its connections, so visitors noticed nothing.
The rule stays in place until our servers run a kernel with the fix, which we install as soon as it is available for them.
Your own server is a different matter. Shieldify protects the traffic that comes through Shieldify. If your server runs Linux and can also be reached directly on its own address, patch it or add the rule below.
Options freed while still in use
When a client opens a TCP connection, its first packet (the SYN) can carry IPv4 options. The kernel keeps those options while the handshake finishes and hands them to the new connection. If the client sends the same SYN again at the right moment, a second CPU can still be reading the options to answer it while they are already being freed. That is a use-after-free in the kernel's network code.
At the least it can crash the server. Red Hat warns it can also corrupt memory, and the kernel's advisory rates it critical because memory bugs like this can be turned into running code in the kernel. It needs no login and no application: an open TCP port over IPv4 is enough, and it happens before your web server or SSH daemon sees anything.
The fix by Eric Dumazet, reported by Xinyang Ge, frees the options only after every reader is done with them. It also covers a similar race when the kernel moves pending connections between listening sockets, which happens only with net.ipv4.tcp_migrate_req=1 or a socket-steering BPF program.
Every Linux server with an open TCP port
The bug came with Linux 4.4, released in 2016. The kernel's advisory lists these releases as fixed:
| Kernel series | Fixed in |
|---|---|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 and later | Fixed from the start |
Most servers run their distribution's kernel, whose version number does not match these. On 30 October Debian had fixed kernels for Debian 12 and 13. Ubuntu listed its releases as vulnerable with fixes in progress, and Red Hat had no fixed package for Red Hat Enterprise Linux yet, which also means none for AlmaLinux and Rocky Linux. IPv6 connections are not affected by the main bug.
Update and reboot. Until then, drop the packets.
1. Update the kernel and reboot
Install your distribution's fixed kernel as soon as it is out. A new kernel only runs after a reboot: uname -r shows the one running now.
2. Until then, drop TCP with IPv4 options
No browser, phone or operating system sends them, so dropping them breaks nothing ordinary. The nftables commands below do it before the kernel's TCP code sees the packet. They last until the next reboot.
3. Leave connection migration off
sysctl net.ipv4.tcp_migrate_req should show 0, the default, unless you know you need it.
4. Keep your origin behind Shieldify
If your website is on Shieldify, let your server accept web traffic only from Shieldify's addresses. Then nobody can send these packets to it directly. Our guide on origin IP leaks shows how.
The interim rule, as root (from Atlas Security's write-up; it does not fix the kernel):
nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop
After the reboot into a fixed kernel the rule is gone. To remove it before that:
nft delete table ip cve_2026_98432
Sources
- The Linux kernel fix, ipv4: free inet_opt and ireq_opt after an RCU grace period (e3f33b0a1d89).
- The CVE record, CVE-2026-98432, published 15 October 2026 by the Linux kernel's CNA, with the fixed releases.
- Red Hat, CVE-2026-98432.
- Debian security tracker, CVE-2026-98432.
- Ubuntu, CVE-2026-98432.
- Atlas Security, CVE-2026-98432: Linux IPv4 TCP use-after-free: the interim nftables rule.
Times are in UTC. Distribution status as of 30 October 2026; check your distribution's page for the latest.