Your Linux Servers Need a Reboot for These Three Kernel Bugs

On September 19, CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog and gave federal agencies until September 21 to deal with them. That was a Sunday.

That timeline comes from BOD 26–04, the directive CISA issued in June to replace the old flat 14 day rule for KEV entries. Under it, a known exploited bug that can hand an attacker full control of a system gets three days, and agencies also have to check whether they were already compromised before the fix went in. You probably don't work for a federal agency. The deadline still matters, because CISA only puts something in the KEV catalog when there's evidence attackers are already using it.

And a kernel fix is a reboot. A reboot needs a signature from whoever owns the app running on that box.

The three bugs

CVE-2025–39682 lives in the kernel's TLS receive path, where zero length records get mishandled badly enough to leak memory or crash the system, and a public proof of concept has been around since September 2025. Next up, CVE-2026–53266 is an out of bounds write in the ebtables SNAT code that bridge Netfilter uses, triggered by a packet with an ARP payload. An attacker needs CAP_NET_ADMIN or something close to it to reach that one, and it can end in local privilege escalation. Rounding it out, CVE-2025–39964 is a race condition in the AF_ALG crypto socket interface that can crash the box or hand back corrupted cryptographic results.

I left the CVSS scores out on purpose. Depending on whose page you read, the AF_ALG bug is anything from a 3.3 at NVD to a 7.8 on the CVE record, and the TLS bug swings between 7.1 and 9.8. Once something is confirmed exploited, that number matters a lot less than whether the bug is sitting on your servers.

Public reporting so far describes local attackers, and nobody has said how the three are being used in actual attacks. People hear "local" and relax. They shouldn't. A local kernel bug is what an attacker reaches for after landing a web shell or a stolen SSH key, because it's the step from a low privilege foothold to owning the server.

Why kernel patches sit

I used to work at a company I'm not going to name, and kernel updates there took way too long to go in. Everybody agreed they mattered. The update command itself took seconds. What held things up was the app owners, who wouldn't approve the downtime a reboot needed, so the servers kept running kernels with known holes in them. Nobody in that building was lazy, and nobody wanted a breach either. Saying no to downtime just felt safer than saying yes. We got lucky. Nothing ever came of it, and I know luck isn't a patching strategy, because that exact habit is what a KEV entry like these three is built to punish.

If that sounds like your shop, the hard part of a three day deadline is getting the reboot approved, and you won't fix your change process by Friday.

What you can do this week

Start by figuring out what you're running. uname -r on each server, compared against your distro's advisory, tells you who's exposed. Red Hat updated its advisories on September 19, and the other major distros publish their own.

Then check whether the vulnerable pieces are even loaded:

lsmod | grep -E 'tls|ebt|af_alg|algif'

lsmod | grep -E 'tls|ebt|af_alg|algif'

Plenty of servers never use kernel TLS. If nothing on the box needs the tls module, unloading and blacklisting it buys time while the reboot gets scheduled, as long as it wasn't compiled straight into the kernel. For the ebtables bug, Red Hat's own guidance is to drop or change any ebtables SNAT rules that rewrite ARP traffic on bridge interfaces, and most servers don't have any to begin with. AF_ALG is the one without a shortcut. Red Hat says no available mitigation meets its standards, so that bug waits on the patch.

Live patching is the other stopgap. Red Hat has kpatch, Canonical has Livepatch for Ubuntu, and SUSE has its own Live Patching service. They can apply some kernel fixes without a reboot, which is exactly what you want when the app owner won't budge. Check that your vendor actually shipped a live patch for these three CVEs before you count on it, because not every kernel fix can be applied live. Most of these services also cost money, so if you don't already pay for one, this week is a bad time to start the procurement process.

Neither stopgap replaces the reboot. They just keep you covered until the reboot happens.

The server nobody will let you reboot

Every environment has one. It runs something important, nobody remembers who set it up, and the last time someone rebooted it the app didn't come back for an hour. That server is where the old kernel lives, and attackers don't care that it's politically awkward to touch.

A server that can't survive a reboot needs a second node behind a load balancer, or at the very least a tested restart procedure, so patching stops being a hostage negotiation. That's a harder conversation than running yum update, and it's the one that keeps the next KEV deadline from turning into a fire drill.

So run uname -r on the server everyone's afraid to touch and drop the kernel version in the comments. No company names needed. I'm curious how old the oldest one out there is.