CVE-2026-98432 on CentOS 7: Fix for ELRepo Kernels

CVE-2026-98432 on CentOS 7 depends on which kernel you boot. The stock 3.10 kernel is not affected, according to Red Hat. ELRepo’s kernel-lt and kernel-ml are: ELRepo’s EL7 kernel channel shipped its last builds in June 2024, so no fix is coming. GetPageSpeed ships the fix as kernel-lt 6.18.60, free for any use, commercial production included. It installs next to your current kernel and takes effect on reboot.

CVE-2026-98432   Linux IPv4 TCP use-after-free, remote and unauthenticated
CVSS 3.1:        9.8 (kernel.org CNA; Red Hat: Critical, 9.8 draft)
Affected:        Linux 4.4 and later
Fixed upstream:  5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
CentOS 7 stock:  kernel 3.10, not affected (Red Hat)
CentOS 7 ELRepo: kernel-lt 5.4.278 and kernel-ml 6.9.7 are the final builds, no fix
CentOS 7 fix:    kernel-lt 6.18.60-2.el7 from the GetPageSpeed corecare channel (x86_64)

How to fix CVE-2026-98432 on CentOS 7

Check the running kernel first:

uname -r

A 3.10.0 kernel needs nothing for this CVE. A kernel ending in .el7.elrepo.x86_64 needs the commands below:

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install yum-utils
yum-config-manager --enable getpagespeed-extras-corecare
yum -y install kernel-lt
grub2-set-default 0
grubby --default-kernel
reboot

The first command also repoints CentOS 7’s dead mirrorlist.centos.org entries at a maintained vault, so yum works again on servers where it had stopped.

Do not skip grub2-set-default 0. On a server pinned to an ELRepo kernel, yum installs the new kernel but the old one stays the default, so a plain reboot brings the vulnerable kernel straight back. Before you reboot, grubby --default-kernel must print the new kernel:

/boot/vmlinuz-6.18.60-2.el7.x86_64

After the reboot, uname -r prints 6.18.60-2.el7.x86_64. The channel stays enabled, so yum update delivers later kernels the same way.

Installed kernel-lt-devel as well? Run yum -y update 'kernel-lt*' to get the matching version, then rebuild any out-of-tree modules against the new kernel.

Already on Everpatch Kernel with a release older than 6.18.56? Run yum -y update kernel-lt, check grubby --default-kernel, and reboot.

What CVE-2026-98432 is

The bug is a race in IPv4 TCP connection setup. tcp_v4_syn_recv_sock() hands a connection request’s IP options to the new child socket without copying them. Another CPU handling a retransmitted SYN can still be building a SYN-ACK from those options when the child socket is freed, which is a use-after-free in ip_options_build(). The CVE record dates the bug to Linux 4.4. The fix frees the options only after an RCU grace period.

Anthropic described the exploit on October 27, 2026. After initial prompting, Claude wrote an exploit that lets a remote attacker run commands as root on Linux servers with a multipath TCP (MPTCP) listener, with no credentials and no user interaction. Its proof of concept takes 48 minutes to leak a kernel pointer and defeat KASLR, then another five minutes to reach command execution. A lost race only fails that handshake and does not crash the system, so an attacker can keep retrying. Repositories publishing proof-of-concept code appeared on GitHub within days.

MPTCP is the demonstrated route, not the boundary of the bug. The Go security team says the underlying bug is not specific to MPTCP and that systems with no MPTCP listener may be open to similar attacks. Red Hat says the flaw affects any vulnerable kernel with IPv4 TCP enabled.

Which CentOS 7 kernels are affected

kernel-ml 6.9.7 is the riskiest row because it matches the demonstrated setup as soon as any program opens an MPTCP listener, and Go 1.24 and later do that by default for listen sockets on Linux. You may not spot one by eye: ss -lnt lists an MPTCP listener like any other TCP port, and the ss on CentOS 7 has no -M option. Check the kernel’s own count instead:

sysctl net.mptcp.enabled
grep -E '^MPTCP ' /proc/net/protocols

The third column of the second command is the number of open MPTCP sockets. kernel-lt 5.4.278 reports no such sysctl and no such protocol.

Why yum update will not fix ELRepo kernels on CentOS 7

ELRepo’s EL7 kernel directory now holds only the elrepo-release package. The final builds were kernel-lt 5.4.278 on June 16, 2024, and kernel-ml 6.9.7 on June 27, 2024, so yum update has nothing to offer. Both branches have also left the kernel.org maintained list, and the CVE record names no fix for 5.4 or 6.9.

ELRepo still ships fixed kernels for EL8 and EL9, so a report that ELRepo kernels are patched does not apply to CentOS 7.

Stopgaps if you cannot reboot yet

Neither of these fixes the bug. Use them only until the reboot.

Turn off MPTCP on kernel-ml 6.9.7:

echo 'net.mptcp.enabled = 0' > /etc/sysctl.d/90-disable-mptcp.conf
sysctl -w net.mptcp.enabled=0

New MPTCP sockets then fail with Protocol not available, but listeners that are already open stay open, so restart the services that own them.

Drop inbound IPv4 TCP packets that carry IP options. This is Red Hat’s rule, and it works with the nftables 0.8 package on CentOS 7:

yum -y install nftables
cat > cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
EOF
nft --check --file cve-2026-98432.nft
nft --file cve-2026-98432.nft
nft list table inet cve_2026_98432

In testing on kernel-lt 5.4.278, kernel-ml 6.9.7 and kernel-lt 6.18.60, a plain connection still succeeded with the rule loaded, while a connection whose SYN carried IP options timed out. Red Hat says the rule reduces exposure but cannot fully prevent exploitation, and AlmaLinux notes that traffic between containers on the same host may bypass it. It does not survive a reboot. Remove it once you run a fixed kernel:

nft delete table inet cve_2026_98432

The init_on_free=1 boot option also narrows what an attacker can learn, but it needs the same reboot, so boot the fixed kernel instead.

Moving from 5.4 or 6.9 to 6.18

Everpatch Kernel uses the same kernel-lt package name as ELRepo and installs side by side, so your old kernel stays on disk and in GRUB.

The commands above were run end to end on the CentOS 7 GenericCloud 2211 image under KVM, starting from a server pinned to ELRepo kernel-lt 5.4.278 and from one pinned to kernel-ml 6.9.7. In both cases kernel-lt 6.18.60-2 booted untainted, with firewalld active, the cgroup v1 memory and cpuset controllers enabled, the network up and no failed systemd units.

On a remote server with no console, you can use grub2-reboot 0 instead of grub2-set-default 0 for the first reboot. It boots the new kernel once, and the next reboot returns to the old default if the new kernel fails to come up. Run grub2-set-default 0 once the new kernel is running, or that next reboot brings the old kernel back.

If something on the new kernel breaks, go back to the old one:

grubby --set-default /boot/vmlinuz-5.4.278-1.el7.elrepo.x86_64
reboot

Use your own version in the path. This restores the vulnerable kernel, so treat it as a way to get a server running again, not as a place to stay.

Everpatch Kernel is x86_64 only, perf is not built yet, and there is no live patching, so taking the fix means a reboot.

FAQ

Is the stock CentOS 7 kernel affected by CVE-2026-98432?

No. Red Hat lists kernel and kernel-rt on RHEL 7 as not affected, and the upstream record dates the bug to Linux 4.4. You do not need to change kernels for this CVE. Other kernel CVEs are a separate question, because the 3.10 kernel stopped receiving updates when CentOS 7 reached end of life in June 2024.

I run ELRepo kernel-lt 5.4, which has no MPTCP. Am I safe?

No. Anthropic’s demonstrated exploit needs an MPTCP listener, so that exact chain does not apply to 5.4. The bug itself is in the regular IPv4 TCP code. Amazon shipped a fix for its own 5.4 kernel, and AlmaLinux says systems without MPTCP still need the fix.

Do I need a GetPageSpeed subscription for the kernel fix?

No. The Everpatch Kernel channel is free for any use, commercial production included, and there is no signup. Packages are signed with the GetPageSpeed key.

Does this kernel work on RHEL 8, RHEL 9, AlmaLinux or Rocky Linux?

No. Everpatch Kernel is built for EL7. Those distributions are affected too, so take the fixed kernel from your vendor when it ships. Red Hat and AlmaLinux publish their own status.

Does the fix need a reboot?

Yes. A new kernel only takes effect after a reboot. The stopgaps above reduce exposure until then.

Why does a Go service matter here?

Go 1.24 and later open listen sockets with MPTCP by default on Linux. On a kernel with MPTCP enabled, that gives the service the listener type used in the demonstrated exploit. GODEBUG=multipathtcp=0 turns it off per program, but the Go security team calls that a fragile mitigation and recommends a patched kernel.

Conclusion

CVE-2026-98432 on CentOS 7 only reaches the kernels people added to get past 3.10, and those are exactly the ones that no longer get updates. kernel-lt 6.18.60 closes the gap under the same package name, side by side with your current kernel, and free for any use.

The rest of the stack has its own clock. If the same server runs PHP, PHP2Shell on CentOS 7 is the next thing to check, and Everpatch for CentOS 7 covers the kernel, PHP and maintained base OS packages together. Everpatch PHP is free to install for personal, development and evaluation use; commercial production use requires GetPageSpeed Ultra ($500/year, up to 10 servers running your own services). Administering servers for clients, or more than 10? GetPageSpeed Fleet starts at $800/year. The kernel stays free either way.