A new Linux kernel vulnerability, CVE-2026-98432, is a use-after-free in the code that sets up incoming IPv4 TCP connections. The Linux kernel CVE team scores it CVSS 9.8 (Critical), with a network attack vector and no privileges or user interaction required. AlmaLinux 8, 9, and 10 are affected. Patched kernels are available in the testing repository today, and we would like your help verifying them before we release them to production.
More information about the vulnerability:
- CVE announcement from the Linux kernel CVE team: https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98432.mbox
- Upstream fix:
e3f33b0a1d89(“ipv4: free inet_opt and ireq_opt after an RCU grace period”)
Summary
When a TCP connection request (a SYN packet) arrives carrying IPv4 options, the kernel keeps a copy of those options with the pending connection so it can echo them back in its reply (the SYN-ACK). When the handshake completes, that copy is handed over to the new connection’s socket as is, without being duplicated.
If the client retransmits its SYN, another CPU can be building a SYN-ACK from those same options at that very moment. Nothing stops the new connection from being closed and its socket freed in the meantime, and the kernel freed the options immediately. The code building the SYN-ACK could then read memory that had already been freed.
A similar problem exists when TCP request socket migration is enabled (the net.ipv4.tcp_migrate_req sysctl, or a BPF program that migrates requests). This setting is off by default.
The bug goes back to Linux 4.4. The fix, written by Eric Dumazet, waits until no other CPU can still be reading the options before freeing them, the same way the kernel already handles them elsewhere.
Impact
The vulnerable code runs inside the kernel while it handles incoming connection requests, before any application sees the connection. It is reached through a SYN packet that carries IPv4 options and is sent to a listening IPv4 TCP port. IPv6 connections are not affected by the main issue.
Any AlmaLinux system that accepts IPv4 TCP connections from untrusted networks should be treated as exposed.
Anthropic, whose researcher reported the bug, has said that its exploit lets a remote attacker run commands as root on Linux servers with a multipath TCP (MPTCP) listener. AlmaLinux ships with MPTCP turned off, so applications cannot open MPTCP listeners unless an administrator has enabled it. The bug itself is in the regular IPv4 TCP code, so systems without MPTCP still need the fix.
Patching ahead of our upstream
Security is a top priority at AlmaLinux, and a flaw rated critical that can be reached over the network is one we do not want to sit on. At the time of writing, no fixed RHEL kernel is available. Our core team has backported the upstream fix to every supported AlmaLinux branch from the Linux stable kernels (5.10, 5.15, and 6.12). The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.
These kernels are available in the testing repository today. After the community has helped verify them, we will release them to the production repositories. This post will be updated when that happens.
Patched kernel versions
- AlmaLinux 8:
kernel-4.18.0-553.180.2.el8_10 - AlmaLinux 9:
kernel-5.14.0-687.61.2.el9_8 - AlmaLinux 10:
kernel-6.12.0-211.69.2.el10_2
Install the version listed for your release, or higher.
Help us test
sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
Confirm with uname -r or rpm -q kernel against the versions above.
If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have rebooted:
sudo dnf config-manager --disable almalinux-testing
If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org.
Temporary mitigation if you cannot reboot yet
The bug can only be triggered by a TCP connection request that carries IPv4 options. Normal traffic almost never uses IPv4 options, so dropping incoming IPv4 TCP packets that carry them blocks the trigger without affecting regular connections.
This command adds an nftables rule that does this. It works alongside firewalld and is safe to run more than once. We tested it on AlmaLinux 8, 9, and 10: connections with IPv4 options are dropped while regular connections keep working.
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -300; policy accept;
meta l4proto tcp ip hdrlength > 5 counter drop
}
}
EOF
The nft command comes from the nftables package, which is installed together with firewalld. If it is missing, install it with sudo dnf install -y nftables first.
The rule does not survive a reboot. If you reboot before you can install the patched kernel, run the command again.
Check that the rule is active. The counter shows how many packets it has dropped:
sudo nft list table ip cve_2026_98432
To remove the rule:
sudo nft delete table ip cve_2026_98432
A few things to keep in mind:
- The rule protects the host and the containers that receive their traffic through it, which is the default for Podman and Docker. Traffic between containers on the same host may bypass it.
- If the system routes traffic for other machines, forwarded TCP packets with IPv4 options are dropped as well.
- Do not use it if your network relies on CIPSO security labels (NetLabel), which are carried in IPv4 options. That setup is not used by default, and in that case the kernel adds the options itself, so the rule would not cover it anyway.
- IPv6 traffic does not need the rule.
Also check MPTCP. It is off by default on AlmaLinux, which removes the setup used in Anthropic’s demonstrated exploit. Confirm that this command prints net.mptcp.enabled = 0:
sysctl net.mptcp.enabled
If it prints 1 and you do not need MPTCP, turn it off and keep it off after a reboot:
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0
This only stops new MPTCP sockets from being created. List the MPTCP listeners that are still open with sudo ss -lnMp and restart the services that own them.
Neither step is a fix. Install the patched kernel and reboot as soon as you can.
Thanks
Thanks to Xinyang Ge for reporting this vulnerability, to Eric Dumazet for writing the upstream fix, to Kuniyuki Iwashima for reviewing it, and to the Linux kernel CVE team.
Thanks to the AlmaLinux core team for turning around patched builds for every supported release, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you in advance to everyone in the community who helps us test these kernels.
Stay informed
Remaining aware of these vulnerabilities and acting quickly can keep your systems and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed. We will update this post when the patched kernels move from testing to production.
