3 new KEV entries in Linux kernel

On 2026-09-18, CISA added three Linux kernel flaws to the Known Exploited Vulnerabilities catalog: CVE-2026-53266 in the ebtables SNAT target, CVE-2025-39964 in the AF_ALG socket layer, and CVE-2025-39682 in the kernel TLS receive path. Three entries against a single subsystem family on one day is unusual and deserves more than a list. This post examines the most consequential in depth, then covers the TLS bug because it shares an exposure pattern worth understanding.

CISA's current KEV remediation directive, BOD 26-04 (Prioritizing Security Updates Based on Risk), took effect on 2026-06-10 and carries the KEV inclusion criteria forward from the 22-01 directive it supersedes. The federal obligation is straightforward: if a CVE is in KEV and it applies to you, remediate on the timeline the catalog specifies for that entry. Private-sector teams should treat the list as the highest-signal patch queue available; entries land there only when CISA has evidence of exploitation in the wild.

The lead: CVE-2026-53266, ebtables SNAT writes into a spliced file page

CISA's summary is dense but precise. The vulnerability lives in the ebtables SNAT target: an ARP sender-hardware-address rewrite triggers an out-of-bounds write that lands inside a nonlinear socket buffer fragment backed by a splice-imported file page. Two elements in that sentence are load-bearing.

The first is where the write lands. Ebtables is the bridge-layer counterpart to iptables. The SNAT target rewrites source addresses on frames traversing a Linux bridge; one of its options rewrites the sender-hardware-address field inside encapsulated ARP payloads. That rewrite normally targets bytes inside the linear region of the sk_buff, the contiguous head the network stack assumes contains protocol headers. When the target bytes fall outside the linear region, the rewrite goes into a fragment. If the fragment is memory the socket owns, the impact is harmful but contained: the attacker corrupts networking state. If the fragment is a page imported from a file via splice(), the impact is fundamentally different. The kernel writes attacker-influenced bytes into the page cache of a file the sending process has spliced.

The second load-bearing element is the trust model. Configuring ebtables rules requires CAP_NET_ADMIN in the relevant network namespace, and unprivileged user namespaces make that capability reachable from an ordinary user account on many distributions. That is what turns a bridge-layer parsing quirk into a general local-attacker primitive: a low-privileged process creates a user namespace, acquires CAP_NET_ADMIN inside it, installs an ebtables rule with a crafted SNAT ARP rewrite, sends a constructed frame, and steers the write into a page it owns via a splice pipe.

The exposure question is not "do you run ebtables." The question is whether unprivileged users on your hosts can reach the code path at all. A quick triage script for a Linux fleet:

#!/usr/bin/env bash
# Triage: is the ebtables SNAT path reachable by unprivileged users?
set -u

echo "kernel: $(uname -r)"

echo -n "unprivileged user namespaces: "
sysctl -n kernel.unprivileged_userns_clone 2>/dev/null \
  || sysctl -n user.max_user_namespaces 2>/dev/null \
  || echo "unknown"

echo -n "ebtables module present: "
modinfo ebtables >/dev/null 2>&1 && echo yes || echo no

echo -n "ebt_snat target present: "
modinfo ebt_snat >/dev/null 2>&1 && echo yes || echo no

echo "modules_disabled: $(sysctl -n kernel.modules_disabled 2>/dev/null)"
echo "seccomp default: check your container runtime profile"

Any host that returns "yes" for the SNAT target module and has unprivileged user namespaces enabled remains in scope until it runs the patched kernel. Multi-tenant Kubernetes worker nodes, CI runners, and shared build hosts should be at the front of the queue. Container hosts that already blocklist unshare(CLONE_NEWUSER) in their seccomp profile, or that set user.max_user_namespaces=0 in namespaces where tenants live, materially raise the bar for a local attacker even before the patched kernel rolls out. That is a useful compensating control while the patch cycle runs, not a substitute for it.

One further point: CISA notes on this entry that "the impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS)" and advises transition to a supported version. In practice, that language points at long-lived vendor kernels past their support window. A KEV entry does not stop applying to an EoL kernel. For EoL kernels, no fix will arrive, and the compensating controls above become the plan rather than a bridge.

The shorter one: CVE-2025-39682, kernel TLS zero-length records

CVE-2025-39682 affects the kernel TLS (kTLS) receive path. CISA describes it as an improper check for unusual or exceptional conditions: a zero-length TLS record retrieved from the receive list rx_list bypasses the intended recvmsg() record-type handling. Subsequent records are processed under incorrect zero-copy and queuing assumptions.

kTLS is the in-kernel TLS record layer used by workloads that take the SSL_sendfile-style optimisation of splicing plaintext through a socket that transparently frames and encrypts (or on receive, decrypts and demuxes) at the kernel boundary. It underlies high-throughput HTTPS servers and some kernel-accelerated proxy configurations. The exposure here is narrower than the ebtables bug: this only matters on hosts that have opted into kTLS on the receive side. A quick check per socket family:

# Are TLS ULPs loaded, and does anything have TLS state?
lsmod | grep -E '^tls\b'
ss -tie state established | grep -i 'tls'

Because the trigger is a peer-supplied record shape rather than an authenticated request, the meaningful attack surface is anything that terminates kTLS receive on data from an untrusted network peer: internet-facing termination, ingress proxies, and any east-west path that treats the other side as untrusted. The EoL/EoS caveat from CISA applies here as well: some vendor forks that shipped kTLS backports may not receive a fix.

Prioritisation

Treat both entries as patch-now under BOD 26-04 timelines and as high priority for private-sector fleets. Recommended order:

1. Rebuild container base images and VM images on a patched upstream stable kernel; roll them through your image-promotion pipeline first, not last.
2. On hosts that cannot reboot immediately, apply the compensating controls above: reduce or remove unprivileged user namespaces on multi-tenant hosts, and audit which workloads need kTLS on the receive side.
3. For workloads on EoL kernels, treat the KEV entries as the forcing function for the migration you have been deferring. There is no "wait for the backport" option.
4. Add detections for the local-exploitation preconditions rather than the exploit itself: unexpected ebtables rule installations inside user namespaces, and new kTLS ULP attachment on sockets that historically did not use it, are both cheap signals.

None of this is theoretical. CISA adds entries to KEV only when it has evidence of active exploitation. Three Linux kernel entries landing on the same day is a signal to verify that your kernel patch cadence is as fast as you tell your auditors it is.

Verifiable security.