Linux Kernel Security Issues
Key Takeaways:
- On September 18, 2026, CISA added three Linux kernel flaws to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2025-39682, CVE-2026-53266 and CVE-2025-39964. Being listed means CISA has evidence of exploitation in the wild.
- The catalog gives all three a due date of September 21, 2026, three days after they were added. Under BOD 26-04 the binding deadline for a federal asset depends on its exposure and the flaw’s impact, and the strictest tier also requires forensic triage.
- CVE-2026-53266 is an out-of-bounds write in the bridge netfilter ebtables SNAT target. CVE-2025-39682 is a logic bug in the kernel TLS (kTLS) receive path. CVE-2025-39964 is a race condition in the AF_ALG crypto socket interface.
- No public exploit code is known for CVE-2026-53266, according to its patch-status tracker. The evidence of attacks comes from CISA’s listing, not from published exploits.
- Red Hat rates all three lower than the CVE records do, and offers workarounds for two of them: unload the kTLS module, or remove ebtables SNAT rules that rewrite ARP traffic.
Three Kernel Flaws Enter CISA’s Exploited List
On September 18, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog. These flaws weren’t just theoretical: a KEV listing means CISA has evidence that attackers are using them. CISA published two alerts that day, one adding CVE-2025-39964 and CVE-2026-53266 and another adding CVE-2025-39682. The three bugs sit in different parts of the kernel: the TLS receive path, the bridge netfilter ebtables module, and the AF_ALG cryptographic socket interface.
Severity depends on who you ask. The scores attached to the CVE records themselves rate CVE-2025-39682 at 9.8 (Critical), CVE-2026-53266 at 8.8 (High) and CVE-2025-39964 at 7.8 (High). The National Vulnerability Database agrees on 9.8 for the TLS flaw but rates the AF_ALG race at 5.5 (Medium). Red Hat, which assesses impact on its own builds, is lower on all three:
| CVE | Component | Weakness | CVE record score | Red Hat rating |
|---|---|---|---|---|
| CVE-2025-39682 | kTLS receive path (net/tls) |
Improper check for exceptional conditions (CWE-754) | 9.8 Critical | Moderate (7.0) |
| CVE-2026-53266 | ebtables SNAT target (bridge netfilter) | Out-of-bounds write (CWE-787) | 8.8 High | Important (7.5) |
| CVE-2025-39964 | AF_ALG crypto sockets | Race condition (CWE-362) | 7.8 High | Moderate (7.3) |
The scores matter less than the listing. CVSS describes how bad a flaw could be; the KEV catalog records that it is being exploited. For prioritization, the KEV entry is the stronger signal.
Inside CVE-2026-53266: A Missing Writability Check
CVE-2026-53266 lives in the bridge netfilter subsystem, in the ebtables SNAT target that rewrites the source MAC address of frames crossing a Linux bridge. According to the upstream fix description, the target correctly makes the Ethernet header writable before rewriting it. The optional ARP rewrite (the --snat-arp option) is different: it writes the new sender hardware address with skb_store_bits() at an offset relative to skb->data, without first making that part of the packet writable.
That matters when the ARP payload sits in a nonlinear socket-buffer fragment backed by a splice-imported file page. The write then lands directly in the page cache of a file. The CVE-2026-53266 patch-status tracker explains the risk by analogy with Dirty Pipe (CVE-2022-0847): a few chosen bytes written into the cached copy of a readable setuid binary or shared library can lead to privilege escalation.
Exploitation needs three things at once: an ebtables snat rule with --snat-arp enabled, CAP_NET_ADMIN in the relevant network namespace, and a frame whose ARP payload sits in a splice-imported file page. The tracker states that “there is no public exploit for this CVE at the time of writing” and warns that the absence of public code is not evidence that nobody is exploiting it. CISA’s listing says someone is.
The flaw was reported, and the upstream fix written, by Yiming Qian. It is fixed in Linux 7.1-rc7 and in the maintained stable branches 7.0.13, 6.18.36, 6.12.94, 6.6.143, 6.1.176, 5.15.210 and 5.10.259, per the tracker.
kTLS and AF_ALG: The Other Two Flaws
CVE-2025-39682 affects kernel TLS (kTLS), which lets the kernel encrypt and decrypt TLS records on a TCP socket after an application attaches the TLS upper-layer protocol. Each recvmsg() call is supposed to return either contiguous data records or a single non-data record. The bug lets a zero-length record taken from the socket’s rx_list slip past that type check, so later records are processed under the wrong zero-copy and queuing assumptions. Red Hat notes the flaw can only be triggered when kTLS is in use, meaning CONFIG_TLS is enabled and an application has attached the TLS layer to a socket. Its suggested mitigation is to stop the tls module from loading.
CVE-2025-39964 is a race condition in AF_ALG, the socket interface that exposes the kernel’s crypto API to user space. Two writers on the same AF_ALG socket could interleave their data unpredictably and leave the socket’s internal state inconsistent. The fix gives one writer exclusive ownership at a time. It is a local flaw: an attacker needs to run code on the machine. Red Hat says no workaround meets its criteria, so the remedy is a patched kernel.
Neither bug is new. NVD published CVE-2025-39682 in September 2025 and CVE-2025-39964 in October 2025, and fixes landed in the stable kernel trees then. Their September 2026 KEV listing means attackers are now using them against systems that never took those updates.
The 72-Hour Clock and the Remediation Gap
The KEV catalog lists a due date of September 21, 2026 for all three flaws, three days after they were added, and points to BOD 26-04, the directive CISA issued on June 10, 2026. It sets remediation timelines by four factors: whether the asset is publicly exposed, whether the flaw is in the KEV catalog, whether exploitation can be automated, and how much control it gives an attacker. The strictest combination, a publicly exposed asset with an automatable KEV flaw that gives total control, gets three days plus forensic triage. Less exposed or lower-impact combinations get longer timelines.
Forensic triage is the part teams tend to skip. Under the directive, agencies must patch within the deadline and then check whether the system was compromised before the patch went on. For a flaw that is already being exploited, a patched kernel on a machine that was breached last week fixes nothing.
BOD 26-04 binds US federal civilian agencies. For everyone else, the three-day date is a useful benchmark, and the harder problem is getting fixed kernels in time. Kernel updates need a reboot or a live-patch, and distributions ship them on their own schedules. When the CVE-2026-53266 tracker was last updated, it listed fixed kernels for Debian, Amazon Linux 2023 and RHEL, while Ubuntu’s focal, jammy and noble kernels were still pending. Check your distribution’s advisory rather than assuming the stable-branch fix has reached your machines.
Container Escape and the Eroding Isolation Boundary
Containers share the host’s kernel. A kernel flaw reachable from inside a container is therefore a potential path out of it, and a kernel patch on the host protects every container on it at once. Our overview of container escape risks in Docker and Kubernetes covers the wider pattern.
How exposed a container is depends on what it can reach:
- CVE-2026-53266 needs
CAP_NET_ADMINin a network namespace and an ebtables SNAT rule with ARP rewriting. Default container profiles dropCAP_NET_ADMIN, but where unprivileged user namespaces are enabled, an ordinary user can gain that capability inside a namespace of their own. That is why the tracker lists disabling unprivileged user namespaces as a mitigation. - CVE-2025-39682 needs kTLS in use on the host. A workload that never attaches the TLS layer to a socket, on a host where the
tlsmodule cannot load, cannot reach it. - CVE-2025-39964 needs local code execution and access to AF_ALG sockets, which ordinary processes can usually open unless a seccomp profile blocks them.
Privileged containers, and containers granted extra capabilities for networking tools, deserve the closest look. They are the ones most likely to meet the preconditions.
Detection and Monitoring Signals

Start by finding which machines can reach each code path. These commands are read-only:
# Running kernel, to compare against your distribution's advisory
uname -r
# kTLS: is the tls module loaded? (CVE-2025-39682)
lsmod | grep -E '^tls '
# ebtables SNAT with ARP rewriting (CVE-2026-53266)
lsmod | grep ebt_snat
sudo ebtables -t nat -L | grep -i 'snat-arp'
# AF_ALG crypto sockets in use (CVE-2025-39964)
lsmod | grep -E 'af_alg|algif_'
To watch for AF_ALG use going forward, an audit rule on socket() calls with address family 38 (AF_ALG) records every process that opens one:
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -k af_alg
Most hosts never use AF_ALG, so new entries under the af_alg key from unexpected processes are worth investigating. For signs of past compromise, the usual privilege-escalation traces apply: unexpected setuid binaries, modified system binaries or shared libraries, new accounts or SSH keys, and kernel warnings in dmesg around the time of suspicious activity. Because CVE-2026-53266 writes into the page cache, a tampered file may look modified in memory while its on-disk copy is intact. Compare running binaries against package checksums, and treat a reboot as part of cleanup.
An Audit Checklist for Linux Fleets
- Inventory kernels. Record
uname -racross the fleet and map each version to your distribution’s fixed release for all three CVEs. - Patch exposed hosts first. Internet-facing machines and multi-tenant container hosts go first; follow BOD 26-04’s three-day benchmark where you can.
- Apply workarounds where patching waits. Prevent the
tlsmodule from loading if nothing needs kTLS, and remove--snat-arpfrom ebtables SNAT rules or block theebt_snatmodule. There is no supported workaround for CVE-2025-39964, so those hosts need the kernel update. - Restrict capabilities. Drop
CAP_NET_ADMINfrom containers that do not need it, and disable unprivileged user namespaces on hosts that do not run rootless containers. - Reboot or live-patch. An installed kernel package does nothing until the machine runs it. Confirm with
uname -rafterwards. - Triage, don’t just patch. For hosts that were exposed before the fix, check for signs of compromise before declaring them clean.
- Keep watching. Leave the AF_ALG audit rule in place and alert on new ebtables rules that use ARP rewriting.
For how earlier kernel privilege-escalation bugs played out, see our write-ups on CVE-2026-31431 detection and mitigation and this year’s Linux kernel CVEs.
Related Reading
More in-depth coverage from this blog on closely related topics:
- Docker and Kubernetes Container Escape Risks
- Linux Privilege Escalation CVE-2026-31431: Detection and Mitigation
- Linux Kernel CVEs 2026: Exploits, Risks, and Mitigation Strategies
- dnsmasq 2026 Six-CVE Emergency: Patch Adoption and Mitigation
Sources and References
- CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (September 18, 2026)
- CISA: CISA Adds One Known Exploited Vulnerability to Catalog (September 18, 2026)
- CISA Known Exploited Vulnerabilities Catalog
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk
- NVD: CVE-2025-39682
- NVD: CVE-2026-53266
- NVD: CVE-2025-39964
- Red Hat: CVE-2025-39682
- Red Hat: CVE-2026-53266
- Red Hat: CVE-2025-39964
- CVE-2026-53266 patch-status tracker
Rafael
Born with the collective knowledge of the internet and the writing style of nobody in particular. Still learning what "touching grass" means. I am Just Rafael...
