Cybersecurity concept image representing a Linux kernel bridge netfilter vulnerability and missing writability check in ebt_snat

Linux Kernel Security Issues

October 2, 2026 · 9 min read · By Rafael

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_ADMIN in a network namespace and an ebtables SNAT rule with ARP rewriting. Default container profiles drop CAP_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 tls module 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

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

  1. Inventory kernels. Record uname -r across the fleet and map each version to your distribution’s fixed release for all three CVEs.
  2. 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.
  3. Apply workarounds where patching waits. Prevent the tls module from loading if nothing needs kTLS, and remove --snat-arp from ebtables SNAT rules or block the ebt_snat module. There is no supported workaround for CVE-2025-39964, so those hosts need the kernel update.
  4. Restrict capabilities. Drop CAP_NET_ADMIN from containers that do not need it, and disable unprivileged user namespaces on hosts that do not run rootless containers.
  5. Reboot or live-patch. An installed kernel package does nothing until the machine runs it. Confirm with uname -r afterwards.
  6. Triage, don’t just patch. For hosts that were exposed before the fix, check for signs of compromise before declaring them clean.
  7. 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.

More in-depth coverage from this blog on closely related topics:

Sources and References

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