CVE-2026-80668 on CentOS 7: Fixed Kernel for EL7

CVE-2026-80668 is a use-after-free in the Linux kernel’s netfilter connection tracking. The kernel.org CNA scores it 9.8, remote and unauthenticated. Red Hat lists the RHEL 7 kernel as affected and ships no fix for it, and CentOS 7 gets no kernel updates at all since June 2024. GetPageSpeed ships the fix as kernel-lt 6.18.62, free for any use, commercial production included. It installs next to your current kernel and takes effect on reboot.

CVE-2026-80668   netfilter conntrack expectation use-after-free
CVSS 3.1:        9.8 (kernel.org CNA, AV:N/AC:L/PR:N/UI:N); Red Hat: Moderate, 7.0 draft
Fixed upstream:  6.1.191, 6.6.160, 6.12.114, 6.18.61, 7.1.5, 7.2
CentOS 7 stock:  kernel 3.10, affected (Red Hat), no CentOS 7 update
CentOS 7 fix:    kernel-lt 6.18.62-2.el7 from the GetPageSpeed corecare channel (x86_64)
Also fixed:      CVE-2026-99270 (TCP, remote), CVE-2026-99109, CVE-2026-89755

How to fix CVE-2026-80668 on CentOS 7

Check the running kernel first:

uname -r

Already on Everpatch Kernel (a version ending in .el7.x86_64 that starts with 6.18)? Update it, check the default and reboot:

yum -y update 'kernel-lt*'
grubby --default-kernel
reboot

grubby --default-kernel must print /boot/vmlinuz-6.18.62-2.el7.x86_64 before you reboot. Older kernel-lt packages installed new kernels without making them the default, so a server that updated to 6.18.60 by yum update alone may never have booted it. 6.18.62-2 moves the default itself whenever the server already boots a kernel-lt. If the check still prints an older kernel, run grub2-set-default 0 and check again.

On the stock 3.10.0 kernel or an ELRepo kernel, install it:

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 that boots a pinned 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:

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

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

Kernel fixed? The PHP on the same server is usually the bigger hole. Remi stopped building PHP for EL7 in June 2024, so if this box serves PHP, see PHP2Shell on CentOS 7: patched builds for every version from 5.4 to 8.4, free to install. Commercial production use needs GetPageSpeed Ultra ($500/year, up to 10 of your own servers) or GetPageSpeed Fleet for servers you run for clients (from $800/year), and that is what funds the next backport. The kernel stays free either way.

What CVE-2026-80668 is

Netfilter’s connection tracking helpers (FTP, SIP, H.323, TFTP and others) read a protocol’s control traffic and create expectations: short-lived entries that let a related data connection through, such as the data channel of an FTP session. Each expectation points back at its master connection, and a timer removed it when it expired.

The CVE record describes a race between that timer and the teardown of the master connection. When the removal loses the race, an expectation can still reach exp->master after the master connection was freed, which is a use-after-free in kernel memory. The fix drops the per-expectation timer and reaps expired expectations from the conntrack garbage collector instead.

The two scores disagree on who can reach it. The kernel.org CNA scenario is an attacker on the network who opens and closes connections through an FTP, SIP or H.323 helper on an internet-facing NAT gateway or firewall, retrying in parallel until the race lands. Red Hat rates it Moderate because the attacker needs traffic that matches an explicitly configured helper policy and precise timing, and it notes that automatic helper assignment is off by default on RHEL. Both agree on the outcome: a crash at least, and memory corruption in the kernel.

No public exploit and no CISA KEV listing exist at the time of writing.

Which CentOS 7 kernels are affected

Upstream, CVE-2026-80668 is a regression that a stable backport brought into 6.1.176, 6.6.143, 6.12.94 and 6.18.24, so the frozen ELRepo kernels predate it. They do carry CVE-2026-99270, a use-after-free in the TCP connection request timer that the CNA scores 8.1 from the network, and nothing on the 5.4 or 6.9 lines will fix it.

Is your server exposed?

The bug needs a conntrack helper that creates expectations. Check which helper modules are loaded:

lsmod | grep -E '^nf_(conntrack|nat)_(ftp|sip|h323|tftp|irc|amanda|pptp|sane|snmp|netbios_ns)'

And whether any expectations exist right now:

cat /proc/net/nf_conntrack_expect

The stock CentOS 7 kernel is more exposed than Red Hat’s note suggests. Its automatic helper assignment is still on:

sysctl net.netfilter.nf_conntrack_helper

net.netfilter.nf_conntrack_helper = 1

With that setting, a loaded helper module attaches itself to every connection on the protocol’s standard port, with no firewall rule asking for it. On a fresh CentOS 7 GenericCloud server with firewalld, no helper was loaded and the default ssh and dhcpv6-client services create no expectations. After firewall-cmd --add-service=ftp, nf_conntrack_ftp and nf_nat_ftp were loaded, and one client sending PASV to port 21 was enough to put an expectation in /proc/net/nf_conntrack_expect. That is the object this CVE frees too early, created by an unauthenticated client.

Kernels from 6.0 on, Everpatch Kernel included, no longer have automatic assignment. A helper only runs where a rule attaches it, so look for those rules:

iptables-save | grep -- '--helper'
nft list ruleset 2>/dev/null | grep 'ct helper'

On kernel-lt 6.18.60 in the same test, firewalld’s ftp service loaded the modules but the same PASV exchange created no expectation.

Empty output does not make a kernel safe. A helper loads the moment a firewall rule or firewalld service asks for it, so treat these checks as a way to rank servers, not as a reason to skip the update. NAT gateways, firewalls in front of FTP servers and VoIP boxes come first.

Stopgap if you cannot reboot yet

This does not fix the bug. Use it only until the reboot, and only if nothing on the server needs the helper: active-mode and passive-mode FTP through this firewall, SIP and H.323 NAT will break.

Remove the firewalld services that pull in helpers, then unload the modules:

firewall-cmd --list-services
firewall-cmd --permanent --remove-service=ftp
firewall-cmd --reload
modprobe -r nf_nat_ftp nf_conntrack_ftp

Repeat for any other helper lsmod listed, such as nf_nat_sip nf_conntrack_sip. Then stop them from loading again:

cat > /etc/modprobe.d/cve-2026-80668.conf <<'EOF'
install nf_conntrack_ftp /bin/false
install nf_nat_ftp /bin/false
EOF

In testing on the stock 3.10 kernel, after these steps the PASV exchange created no expectation, even with the ftp service added back. Delete /etc/modprobe.d/cve-2026-80668.conf once you run a fixed kernel.

Also fixed in 6.18.62

All three are fixed upstream in 6.18.61 and were present in kernel-lt 6.18.60-2.

Moving 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.

Both command blocks above were run end to end against the live repository on the CentOS 7 GenericCloud 2211 image under KVM. From the stock 3.10 kernel, yum -y install kernel-lt left 3.10.0 as the default until grub2-set-default 0 moved it, and the server came back on 6.18.62-2.el7.x86_64. From a server booting kernel-lt 6.18.60-2, yum -y update 'kernel-lt*' alone made 6.18.62-2 the default, and a plain reboot came up on it. Both ended with 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-3.10.0-1160.119.1.el7.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-80668?

Yes. Red Hat lists kernel and kernel-rt on RHEL 7 as affected and rates the flaw Moderate. CentOS 7 reached end of life in June 2024, so no CentOS 7 kernel update will follow.

Why does Red Hat say Moderate when the CVE says 9.8?

The kernel.org CNA scores the worst case: an internet-facing gateway with a conntrack helper and an attacker who can drive the race over the network. Red Hat scores a typical RHEL host, where helpers are not assigned automatically, and rates the result as mostly a crash. CentOS 7’s 3.10 kernel still assigns them automatically (net.netfilter.nf_conntrack_helper = 1), so if a helper is loaded, the CNA’s scenario is the one that describes your server.

I run ELRepo kernel-lt 5.4.278. Do I need this?

Not for CVE-2026-80668, which entered the stable lines after ELRepo’s last EL7 build. You do need a fixed kernel for CVE-2026-99270 and for CVE-2026-98432, and ELRepo’s EL7 kernels get no more updates.

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.

Does the fix need a reboot?

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

Conclusion

CVE-2026-80668 reaches every kernel a CentOS 7 server is likely to run: the stock 3.10 kernel per Red Hat, and Everpatch Kernel up to 6.18.60. kernel-lt 6.18.62 fixes it, together with the remote TCP bug that also sits unfixed in ELRepo’s frozen kernels, under the same package name 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.