CVE-2026-53266: Linux Kernel ebtables SNAT Out-of-Bounds Write via Splice-Imported Socket Buffers

Background

ebtables is the Linux kernel’s Ethernet-frame filtering and NAT framework, sitting alongside iptables/nftables in the netfilter subsystem but operating at Layer 2 rather than Layer 3/4. It is used to filter, rewrite, and NAT traffic based on MAC addresses and other link-layer attributes, and is commonly deployed on Linux-based bridges, virtualization hosts, and network appliances that need Layer 2 traffic manipulation — including the SNAT (Source Network Address Translation) target, which can rewrite source addressing information in outgoing frames.

CVE-2026-53266 is a vulnerability in the ebtables SNAT target’s handling of ARP frames. CISA’s advisory notes that the impacted product(s) could be end-of-life (EoL) or end-of-service (EoS), and advises affected users to discontinue use and/or transition to a supported kernel version — a notable signal that this flaw may primarily affect older kernel branches that are no longer receiving routine security backports.

Technical Mechanism

CVE-2026-53266 is classified under CWE-787 (Out-of-Bounds Write). The vulnerability specifically involves the ebtables SNAT target’s ARP-handling code path, where an “ARP sender hardware address rewrite” operation writes directly into a nonlinear socket-buffer (skb) fragment that is backed by a splice-imported file page.

To unpack that: Linux network buffers (skbs) can be nonlinear, meaning their data is spread across multiple memory fragments rather than one contiguous allocation — this happens routinely with zero-copy techniques like splice(), which can import pages directly from a file into a socket buffer’s fragment list without a data copy, for performance. The ebtables SNAT target, when rewriting the ARP sender hardware address field as part of its NAT logic, writes into the skb at an offset calculated for a conventional, linearly-allocated buffer. When the underlying fragment is instead a splice-imported file page, that write can land outside the bounds of the intended buffer region — corrupting adjacent kernel memory or the file-backed page itself.

Conceptual attack flow:

1. An attacker positions a workload (local or, on bridged/virtualized infrastructure, a guest or adjacent tenant) capable of triggering splice()-based nonlinear socket buffer construction combined with ARP traffic that passes through an ebtables SNAT rule.
2. The attacker sends or triggers processing of a crafted ARP frame that causes the ebtables SNAT target’s sender hardware address rewrite logic to execute against the nonlinear, splice-backed buffer.
3. The kernel writes the rewritten hardware address bytes at the expected linear offset, which — because the buffer is fragmented and file-backed — writes out of bounds relative to the intended destination.
4. Depending on what memory lies adjacent to the corrupted region, this can corrupt kernel heap structures, crash the host (denial of service), or under favorable memory layout conditions, be leveraged toward further memory-corruption primitives.

Out-of-bounds writes in kernel space are a well-established vector for progressing from a memory-safety bug to privilege escalation or arbitrary code execution, though the specific exploit chain achievable here depends on kernel version, build hardening (KASLR, CFI, etc.), and the surrounding heap layout at exploitation time.

Real-World Exploitation Evidence

CISA added CVE-2026-53266 to the Known Exploited Vulnerabilities catalog on 18 September 2026 — confirming, by the nature of KEV listing, that active exploitation in the wild has been observed or credibly reported. KEV entries are not issued for theoretical or proof-of-concept-only vulnerabilities.

No specific threat actor, campaign, or intrusion set is named in the available KEV record. No specific threat actor has been publicly attributed to exploitation of this CVE; its KEV listing confirms active exploitation in the wild, but attribution detail is not yet public. Kernel-level memory corruption bugs of this type are historically valuable to actors seeking local privilege escalation after an initial foothold, or to operators of malicious virtualization/container tenants attempting to break out of isolation boundaries — but no such specific use has been confirmed for this CVE.

The knownRansomwareCampaignUse field is marked “Unknown” for this entry — CISA has not confirmed ransomware use of this CVE at this time.

Impact Assessment

Kernel out-of-bounds write vulnerabilities carry severe potential impact because the kernel operates with unrestricted access to the entire system:

• Availability: The most immediately achievable outcome of an out-of-bounds write is memory corruption severe enough to crash the kernel (a kernel panic), yielding denial of service against the affected host.
• Integrity and confidentiality: Depending on what adjacent kernel structures are overwritten, an attacker may achieve local privilege escalation to root, or corrupt data structures in a way that leaks adjacent kernel memory contents.
• Multi-tenant risk: Because the bug is reachable via ebtables SNAT processing combined with splice-based buffer construction — both of which are plausible on bridged network configurations used in container and VM networking — hosts running multi-tenant workloads (cloud infrastructure, shared hosting, CI/CD runners) carry elevated risk of guest-to-host or container-to-host escape scenarios if this primitive can be weaponized that way.

Sector-specific risk: This affects any Linux deployment using ebtables SNAT rules on bridged network interfaces — common on virtualization hosts (KVM/libvirt bridges), container network stacks, and network appliances built on Linux. Given CISA’s note about end-of-life exposure, organizations running older, unsupported Linux kernel branches on network infrastructure are at the highest risk, since no vendor patch may be forthcoming for those branches.

Affected Versions

The precise affected kernel version range is not included in the provided KEV data. Organizations should consult the upstream kernel stable-tree commits referenced in CISA’s notes (linked below) for the exact versions in which the fix landed, and cross-reference against their running kernel version.

CISA explicitly flags that impacted products could be end-of-life or end-of-service — if your deployment runs an unsupported kernel branch, treat this as unpatchable without an upgrade.

Remediation Steps

CISA’s required action directs organizations to apply vendor/distribution mitigations per BOD 26-04, follow Forensics Triage Requirements, or discontinue use of affected end-of-life systems.

1. Identify the running kernel version on all Linux systems using ebtables, particularly bridged virtualization hosts and network appliances:

uname -r
cat /etc/os-release

2. Check whether ebtables SNAT rules are in active use:

ebtables -t nat -L

3. Apply the kernel update from your distribution that incorporates the upstream fix commits referenced in CISA’s notes (see References) — for most mainstream distributions this will arrive as a routine kernel security update.

4. For end-of-life kernel branches with no available patch, plan migration to a supported, actively maintained kernel/distribution release as a priority — per CISA’s guidance, discontinuing use of the unpatched product is the recommended path where mitigation is unavailable.

5. As a defense-in-depth interim measure, where ebtables SNAT on ARP traffic is not required, disable or remove the specific SNAT rules affecting ARP frames until patched.

Detection Guidance

Exact detection signatures for kernel-level memory corruption require kernel crash-dump and dmesg analysis rather than network signatures:

• Kernel log monitoring: Watch dmesg / kernel logs for unexpected panics, BUG: or KASAN: warnings referencing the netfilter bridge/ebtables code paths, or slab corruption messages following ARP traffic processing.
• Crash dump analysis: Any unexplained kernel panic on hosts running ebtables SNAT on bridged interfaces should be triaged with a kernel crash dump (kdump) to rule out exploitation attempts versus unrelated instability.
• Host-based monitoring: On virtualization and container hosts, correlate kernel instability events with guest/container activity timing to identify potential guest-triggered exploitation attempts.
• Vendor/distribution advisories: Consult your Linux distribution’s security team and any available IDS signature feeds for CVE-2026-53266-specific detection content, as exact exploitation signatures have not been publicly detailed.

Timeline

References

• Linux kernel stable fix — git.kernel.org commit bf84ad7c7a9e
• Linux kernel stable fix — git.kernel.org commit 76280b78cc9f
• Linux kernel stable fix — git.kernel.org commit b7e91939ba9b
• Linux kernel stable fix — git.kernel.org commit afd64b59c3de
• Linux kernel stable fix — git.kernel.org commit 153ea96c806a
• Linux kernel stable fix — git.kernel.org commit b18675263db1
• Linux kernel stable fix — git.kernel.org commit c9b5ff59feff
• Linux kernel stable fix — git.kernel.org commit 67ba971ae025
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA — BOD 26-04 Implementation Guidance: Forensics Triage Requirements
• NVD — CVE-2026-53266