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

by Danila Vershinin, November 8, 2026

Scalable Stories

00:00 / 00:14:34

Technical Briefing: CVE-2026-80668, a Netfilter Conntrack Use-After-Free, and the Fixed Kernel for CentOS 7

Today’s source is a GetPageSpeed article on CVE-2026-80668, a use-after-free in Linux netfilter conntrack expectation handling. It covers which CentOS 7 kernels are affected, how to install the fixed Everpatch Kernel kernel-lt 6.18.62-2.el7, how to judge exposure, and a stopgap for servers that cannot reboot yet. Earlier briefings covered PHP on CentOS 7 and CentOS 6 and the Brotli flaw, so this briefing does not re-explain them. Commands, versions and caveats are as stated in the article.

The Problem

The vulnerability

Item	Detail
Type	Use-after-free in netfilter conntrack expectation handling
kernel.org CNA score	CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N): remote and unauthenticated
Red Hat score	Moderate, 7.0 draft
Fixed upstream	6.1.191, 6.6.160, 6.12.114, 6.18.61, 7.1.5 and 7.2
Introduced by	A regression from stable backports into 6.1.176, 6.6.143, 6.12.94 and 6.18.24
Status	No public exploit and no CISA KEV listing yet

How the bug works

Conntrack helpers create short-lived “expectations” that let related data connections through. Examples are FTP, SIP, H.323, TFTP and IRC.
Each expectation points back at its master connection. It was removed by a per-expectation timer.
That timer races with teardown of the master connection. If removal loses the race, the expectation can still reach exp->master after the master was freed.
Upstream fix: the per-expectation timer is dropped. The conntrack garbage collector now reaps expired expectations.

Why the two scores differ

CNA worst case: an attacker on the network opens and closes connections through an FTP, SIP or H.323 helper on an internet-facing NAT gateway or firewall. The attacker retries in parallel until the race lands. The result is at least a crash, plus kernel memory corruption.
Red Hat’s reasoning: exploitation needs traffic that matches an explicitly configured helper policy, plus precise timing. Red Hat also notes that automatic helper assignment is off by default on RHEL.

Why stock CentOS 7 is stranded

Red Hat lists the RHEL 7 kernel and kernel-rt as affected but ships no fix.
CentOS 7 has received no kernel updates since its end of life in June 2024.

The Implementation: Everpatch Kernel `kernel-lt 6.18.62-2.el7`

Package details

Channel: getpagespeed-extras-corecare, x86_64 only.
Cost: free for any use, including commercial production, with no signup.
Signing: packages are signed with the GetPageSpeed key.
Package name: it uses the same kernel-lt package name as ELRepo.
Installation behavior: it installs side by side with the existing kernel. The old kernel stays on disk and in GRUB. The fix takes effect on reboot.

Additional CVEs fixed

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

CVE	Component	CNA score	Vector
CVE-2026-99270	TCP: use-after-free in `reqsk_timer_handler()`	8.1	Network
CVE-2026-99109	SMB client: SetEA requests that overflow the request buffer	7.8	Local
CVE-2026-89755	mm/migrate_device: stale mapping after freeing swapcache	7.8	Local

Which CentOS 7 Kernels Are Affected

Kernel	CVE-2026-80668	CVE-2026-99270 (TCP)	Action
Stock 3.10.0	Affected, no update	Not affected	Install fixed kernel
ELRepo kernel-lt 5.4.278 (June 2024)	Outside affected ranges	Bug present, no fix	Install fixed kernel
ELRepo kernel-ml 6.9.7 (June 2024)	Outside affected ranges	Bug present, no fix	Install fixed kernel
Everpatch before 6.18.61 (6.18.60-2)	Affected	Affected	`yum -y update 'kernel-lt*'`
Everpatch 6.18.62-2	Fixed	Fixed	Nothing

Why ELRepo kernels escape this CVE: ELRepo’s frozen EL7 kernels predate the regression-introducing backports.
Why they still need replacing: they carry CVE-2026-99270. Per the article’s FAQ, they also carry CVE-2026-98432. Nothing on the 5.4 or 6.9 lines will fix either.

Applying the Fix

Step 1: Check the running kernel

uname -r

Step 2a: Already on Everpatch Kernel

This applies if the version starts with 6.18 and ends in .el7.x86_64.

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

Before you reboot, grubby --default-kernel must print /boot/vmlinuz-6.18.62-2.el7.x86_64.
Caveat: older kernel-lt packages installed new kernels without making them the default. A server that reached 6.18.60 via yum update alone may never have actually booted it.
6.18.62-2 now 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.

Step 2b: On the stock 3.10.0 kernel or an ELRepo kernel

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

Side benefit: the first command also repoints CentOS 7’s dead mirrorlist.centos.org entries at a maintained vault. This makes yum work 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 leaves the old one as default, so a plain reboot brings the vulnerable kernel straight back.
Before reboot, grubby --default-kernel must print /boot/vmlinuz-6.18.62-2.el7.x86_64.
After reboot, uname -r prints 6.18.62-2.el7.x86_64.
The channel stays enabled, so yum update delivers later kernels the same way.

Tested results

Both command blocks were run end to end against the live repository on the CentOS 7 GenericCloud 2211 image under KVM.

From stock 3.10: yum -y install kernel-lt left 3.10.0 as the default until grub2-set-default 0 moved it.
From 6.18.60-2: yum -y update 'kernel-lt*' alone made 6.18.62-2 the default.
Both paths ended with the network up and no failed systemd units.

Remote servers with no console

For the first reboot, use grub2-reboot 0 instead of grub2-set-default 0. It boots the new kernel once. If the new kernel fails to come up, the next reboot returns to the old default.
Once the new kernel is running, run grub2-set-default 0. Otherwise the next reboot brings the old kernel back.

Rollback

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. Treat it as a way to get running again, not a place to stay.

Limitations

x86_64 only.
perf is not built yet.
No live patching, so taking the fix means a reboot.
EL7 only. It does not work on RHEL 8/9, AlmaLinux or Rocky Linux. Those are affected too and should take the fix from their vendor.

Assessing Exposure

Check for loaded helper modules and live expectations

Loaded helper modules:

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

Current expectations:

cat /proc/net/nf_conntrack_expect

Stock 3.10 is more exposed than Red Hat’s note suggests

Automatic helper assignment is still on:

sysctl net.netfilter.nf_conntrack_helper
net.netfilter.nf_conntrack_helper = 1

With this setting, a loaded helper attaches itself to every connection on the protocol’s standard port, with no firewall rule asking for it.
So if a helper is loaded on stock CentOS 7, the CNA’s 9.8 scenario is the one that describes your server.

Test findings on stock 3.10 with firewalld

On a fresh GenericCloud server, no helper was loaded. The default ssh and dhcpv6-client services create no expectations.
After firewall-cmd --add-service=ftp, nf_conntrack_ftp and nf_nat_ftp loaded.
A single unauthenticated client then sent PASV to port 21. This created an expectation in /proc/net/nf_conntrack_expect, which is exactly the object this CVE frees too early.

Kernels 6.0+ (including Everpatch)

These kernels have no automatic assignment. A helper only runs where a rule attaches it, so check for such rules:

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

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

How to use these checks

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

Stopgap If You Cannot Reboot Yet

This does not fix the bug.

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

Step 1: Remove helper-pulling firewalld services and 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 that lsmod listed (e.g., nf_nat_sip nf_conntrack_sip).

Step 2: Block the modules from reloading

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

On stock 3.10, 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.

Practical Payoff

Who needs to act: CVE-2026-80668 reaches every kernel a CentOS 7 server is likely to run. That means stock 3.10 (per Red Hat) and Everpatch up to 6.18.60. ELRepo kernels escape this CVE but still carry the unfixed remote TCP bug.
One package closes all of it: kernel-lt 6.18.62 fixes all of these under the same package name. It is free for any use, including commercial production.

Related note (PHP, covered in earlier briefings): the article advises checking PHP next on PHP-serving boxes, where PHP is often the bigger hole.

Remi stopped building PHP for EL7 in June 2024.
Everpatch PHP offers patched builds for 5.4 through 8.4.
Free use: personal, development and evaluation.
Commercial production: requires GetPageSpeed Ultra ($500/year, up to 10 servers running your own services). For client servers or more than 10 servers, it requires GetPageSpeed Fleet (from $800/year).
The kernel stays free either way.

Read the full article: CVE-2026-80668 on CentOS 7: Fixed Kernel for EL7