CRITICAL: Linux Kernel Gets Three CISA KEV Entries With a Sept 21 Deadline

Pour one out for whoever was on call this weekend. CISA dropped three Linux kernel vulnerabilities into the Known Exploited Vulnerabilities catalog on September 18, and the remediation deadline for federal civilian agencies under Binding Operational Directive 26-04 landed on September 21. That is three days, across a weekend, for a patch that requires a reboot on machines nobody likes rebooting. Red Hat issued its advisories on September 19 and acknowledged active exploitation, which is the polite corporate way of saying this is no longer theoretical.

The three flaws are CVE-2025-39682 in the kernel TLS receive path, CVE-2026-53266 in the ebtables bridge netfilter code, and CVE-2025-39964 in the AF_ALG crypto socket interface. None of them is a glamorous pre-authentication remote code execution bug with a catchy logo and a dedicated website. All three are the unglamorous kind that turns a foothold into root, which is exactly the kind attackers actually use once they are already inside.

What the bugs actually do

CVE-2025-39682 is the headliner, and it is also the one with the most confusing paperwork. The Linux kernel CNA scored it 9.8 critical with a network attack vector, while NVD assessed it at 7.1 high with a local vector and low privileges required. That gap matters, and anyone building a patch priority list off a single number is going to get it wrong in one direction or the other. Reading the actual fix explains the disagreement. The bug lives in how the kernel TLS code handles zero length records sitting on the rx_list. Each recvmsg call is supposed to process either a run of contiguous data records or exactly one non data record. Under TLS 1.3 the kernel does not know the record type until after decryption, so a pending record gets queued to the rx_list for the next call to pick up. Zero copy decryption writes straight into the user space buffer, which means there is no socket buffer left to queue, and the corner case the developers missed is an initial record that comes off the rx_list with zero length. The result is memory disclosure or a denial of service against a process that was trusting its own TLS session. Red Hat was blunt about the risk, stating that the flaw is high risk and that there are known public exploits leveraging it. The practical read is that this is a local issue for most deployments, but if you terminate TLS in the kernel with kTLS offload, the exposure window widens considerably and the CNA score starts looking less like hyperbole.

CVE-2026-53266 carries a CVSS 3.1 score of 8.8 and is an out of bounds write, classified as CWE-787, with a changed scope. The ebtables SNAT target deliberately guards its Ethernet source address rewrite behind a writability check, because at the bridge hooks the Ethernet header is reached through the MAC header pointer while the socket buffer data pointer sits at the payload. That much was correct. The optional ARP sender hardware address rewrite is where it falls apart, because that path writes through skb_store_bits at an offset relative to the data pointer without ever making the target range writable. If the sender hardware address range is still living in a nonlinear fragment backed by a spliced file page, the kernel happily maps that page and copies a new MAC address directly into it. Writing attacker influenced bytes into a page that belongs to a file is the sort of primitive exploit developers frame and hang on the wall. The fix ensures the ARP range is writable before the header is read and before the store happens.

CVE-2025-39964 is the quietest of the three at 7.8 from the kernel CNA and 5.5 from NVD, and it is a textbook race condition under CWE-362. Issuing two concurrent writes to the same AF_ALG socket interleaves the data unpredictably and leaves the internal socket state inconsistent. The patch adds an exclusive ownership flag so a second writer cannot barge in. On its own this reads like a crash bug and a data integrity problem for anything doing kernel crypto through the userspace algorithm interface. Chained behind one of the other two, inconsistent internal state in a crypto socket is a useful place to start corrupting things.

Who should care and how this looks in the wild

Everyone running Linux is in scope for at least one of these, which is an unhelpfully large audience, so it is worth narrowing. The TLS bug matters most where kTLS is actually enabled, which in practice means high throughput proxies, load balancers, content delivery nodes and storage front ends that offloaded TLS for the performance win. The ebtables flaw matters where bridge level filtering is in use, which quietly describes a very large share of container hosts, virtualization platforms and anything running a Linux bridge with netfilter rules attached. The AF_ALG race matters anywhere userspace reaches into kernel crypto, including some VPN and disk encryption tooling.

Honesty about what is not known is more useful than speculation. There are currently no public details on how these three are being exploited in the wild, and CISA did not name a threat actor or a campaign. What is documented is that public exploit code exists for the TLS flaw and that CISA saw evidence strong enough to justify a three day federal deadline, which the agency does not hand out casually.

There is a second Linux story running in parallel this week, and it is worth keeping the two separate rather than assuming they are the same event. Researcher Asim Manizada disclosed four local privilege escalation flaws reported to the kernel security team in mid July, publishing working exploits on September 18. Those are CVE-2026-80844 in the IPsec AH6 code, CVE-2026-81000 in TUN and TAP virtual network devices, CVE-2026-68121 in PPPoE, and CVE-2026-74469 in the SCTP diagnostic interface, informally named DirtyAH6, TUNderflow, PPPoEject and DiagSpill. Whether any of that activity relates to the KEV additions remains undetermined. The timing is suggestive, the evidence is not there yet, and pretending otherwise helps nobody.

What to do about it

Patch, and do it through your distribution rather than chasing upstream tags. Red Hat, Ubuntu, SUSE and Debian all backport kernel fixes into their own version schemes, so a mainline version number tells you very little about whether your RHEL box is safe. For the four separately disclosed privilege escalation bugs, the first upstream stable releases carrying all the fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4, which is a reasonable sanity check if you build your own kernels. Everyone else should be reading their vendor advisory and nothing else.

If you cannot reboot fleet wide this week, there are real mitigations rather than wishful ones. Turning off unprivileged user namespaces closes the ordinary user path to three of the four separately disclosed flaws and is generally good hygiene on servers that have no business creating namespaces. Disabling networking features you do not use shrinks the attack surface directly, and that means unloading or blacklisting AH6, TUN and TAP, PPPoE and SCTP where they are not required. If you are not doing bridge level filtering, the ebtables modules do not need to be loaded either. Live patching through kpatch, Ksplice, Canonical Livepatch or the equivalent buys time on systems where the reboot window is genuinely weeks out.

For detection, kernel exploitation is noisy if you are listening. Watch for kernel oops and panic messages appearing in clusters rather than in isolation, because a failed privilege escalation attempt usually crashes something before it succeeds. Alert on unexpected kernel module loads, on processes opening AF_ALG sockets when nothing in your stack should be doing kernel crypto through userspace, and on unprivileged processes creating user namespaces on servers where that never happens. Auditd rules around setns and unshare are cheap and catch a surprising amount. A process suddenly running with a UID of zero when its parent was unprivileged is the signal that matters most, and any decent EDR should be able to express that.

The uncomfortable truth in all of this is that local privilege escalation bugs get triaged last and exploited first. A phishing email or an exposed web application gets an attacker a shell as an unprivileged service account, and bugs like these three are what turn that into full control of the host. Treating them as low priority because the attack vector says local is exactly the reasoning attackers are counting on.

The MSP angle

Kernel patching is the single most deferred maintenance item in every client environment, which makes a three day federal deadline the easiest conversation starter of the quarter. This is the moment to sell managed kernel patching with live patching capability as a recurring line item rather than firefighting each KEV addition for free. Clients running container or virtualization platforms are especially exposed here, and a paid kernel and host hardening assessment covering module blacklisting, namespace restrictions and reboot scheduling turns a scary advisory into a scoped engagement with a real deliverable.