CVE-2026-98432, a use-after-free bug in the Linux kernel’s TCP over IPv4 code rated 9.8 under CVSS 3.1 by the kernel security team, affects every server running kernel 4.4 or later and is fixed by updating the kernel and rebooting. The fix has landed in the stable branches and Debian has shipped packages, but Ubuntu and Red Hat are still preparing them for many of their releases. Here is how to check whether a system is exposed and how to update it.
Patching CVE-2026-98432 in 20 seconds
- It affects Linux 4.4 and later; fixed stable releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10.
- Debian has fixes for trixie and bookworm; Ubuntu and Red Hat are still working on theirs.
- Install the new kernel as soon as your distribution ships it, then reboot so it takes effect.
The bug lives in tcp_v4_syn_recv_sock(). When the kernel creates the full socket for a new connection, it hands over the IP options of the original request without copying them, so a retransmitted SYN processed in parallel can read them after they have been freed. A remote, unauthenticated attacker could at the very least crash the kernel. The kernel team scores it 9.8, while Red Hat lowers it to 5.9 and Amazon to 7.0 because the attacker has to win a race condition. No active exploitation has been reported. For the wider impact on servers and cloud deployments, see the analysis published by Revista Cloud (in Spanish).
How to tell whether a server is affected
Start by checking which kernel is actually running, which may not match the one installed if the machine has not been rebooted:
uname -r
If you run a stable kernel built from kernel.org, compare it with the fixed releases. Distribution kernels use their own version numbers because each vendor carries its own patches, so rely on their advisories instead. Debian ships the fix in kernel 6.12.113-1 for trixie (DSA-6568-1) and 6.1.190-1 for bookworm (DLA-4841-1). Ubuntu lists fixes in progress for 22.04 (5.15.0-203), 24.04 (6.8.0-149), 26.04 (7.0.0-43) and 26.10 (7.3.0-10), but had not published them as of 28 October; 20.04, 18.04 and 16.04 are listed as vulnerable with no fix date. Red Hat has deferred the fix for RHEL 8, 9 and 10, and RHEL 7 is not affected.
It is also worth checking whether TCP request migration is enabled, since it opens the second path to the bug. The default value is 0:
sysctl net.ipv4.tcp_migrate_reqCode language: CSS (css)
Updating Debian, Ubuntu and RHEL
On Debian and Ubuntu, the kernel is updated with the rest of the packages. The first command refreshes the repositories, the second shows whether a new kernel is available and the third installs it:
sudo apt update
apt list --upgradable 2>/dev/null | grep linux-image
sudo apt full-upgradeCode language: JavaScript (javascript)
On Ubuntu, the file /var/run/reboot-required tells you when a reboot is needed. On RHEL, Rocky Linux, AlmaLinux and derivatives, once the package is out:
sudo dnf update kernel
rpm -q kernel
In every case the fix only protects you once the system boots the new kernel, so reboot and run uname -r again. On cloud virtual machines this is the customer’s job, including provider-specific kernels such as linux-aws, linux-azure or linux-gcp on Ubuntu.
What to do until a patch is available
Red Hat does not recommend any specific mitigation. The sensible approach is to shrink the attack surface: close firewall ports that do not need to face the internet, put management services behind a VPN or an IP allowlist, and leave net.ipv4.tcp_migrate_req and BPF request-migration programs disabled. Since the main bug does not affect IPv6, services listening only on IPv6 are outside that scenario. And subscribe to your distribution’s security announcement list so you can patch as soon as packages ship.
Frequently asked questions
How do I know if my kernel is patched against CVE-2026-98432?
Check the running kernel with uname -r and compare it with your distribution’s security advisory. For kernel.org kernels, fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10 or later.
Do I need to reboot?
Yes. The new kernel is only used after a reboot.
Is it being exploited?
Not that anyone has reported. None of the official sources mention attacks or a public proof of concept.
Sources:
