CVE-2026-53266

What is ebtables?

ebtables is the Linux filtering framework for Ethernet bridges, the layer-2 counterpart to iptables. Where iptables sees IP packets being routed, ebtables sees frames being switched between ports of a software bridge, and it can filter or rewrite them at the MAC layer. Its snat target rewrites the source MAC address of a frame, and has an option, --snat-arp, to also rewrite the sender hardware address inside an ARP payload so that the frame and the ARP announcement it carries stay consistent.

Bridges are everywhere in modern Linux infrastructure even when nobody set one up by hand. Every KVM or libvirt host bridges guest interfaces, Docker's default networking is a bridge, and Kubernetes CNI plugins, OpenStack compute nodes, and cluster-node network appliances all put frames through br_netfilter. That places ebtables code on the packet path of hosts that are shared by many tenants.

Overview

CVE-2026-53266 is an out-of-bounds write in the ebtables SNAT target's ARP rewrite path. When the target rewrites the ARP sender hardware address it calls skb_store_bits() at an offset relative to skb->data without first ensuring that the target range is actually writable by this code path.

For a normal linear packet that assumption holds. It does not hold for a nonlinear socket buffer whose fragments are backed by pages the kernel does not own outright, in particular pages imported through splice() from a file. In that case the write goes straight into the backing page: page cache belonging to a file on disk, or memory mapped by an unrelated process. The result is memory corruption that reaches well outside the packet buffer, which is why the kernel CNA scored it 8.8 with a changed scope.

Red Hat scores it 7.0, differing mainly on attack complexity, because lining up an ARP payload in a splice-backed fragment at the right offset is fiddly rather than automatic. CISA added the CVE to KEV on 2026-09-18 with a three-day remediation deadline, so the practical question of whether that complexity deters attackers has been answered.

Affected Versions

The bug was introduced in 5.10 by commit 63137bc5882a, a fix for a small-packet regression, and that commit was also backported into 5.4.73, 5.8.17 and 5.9.2, so those older stable series are affected too. Hosts that never load the ebtable_nat or ebt_snat modules do not expose the vulnerable path.

Technical Details

CWE-787, out-of-bounds write: code writes past the region it is entitled to modify. The specific omission is that the ARP sender hardware address range was never made writable before being written. The kernel has an explicit contract for this, skb_ensure_writable(), which linearizes or copies the relevant range and breaks any sharing of the underlying pages first. The upstream fix, "netfilter: bridge: make ebt_snat ARP rewrite writable", adds that call before both the ARP header read and the skb_store_bits() write.

The attacker needs two things. First, CAP_NET_ADMIN in the relevant network namespace, in order to install an ebtables snat rule with the ARP rewrite option. That is a real constraint on a hardened host, but it is weaker than it sounds: on systems where unprivileged user namespaces are enabled, an ordinary user can create a namespace pair in which they hold CAP_NET_ADMIN, and a container workload granted NET_ADMIN has it outright. Second, a frame carrying an ARP payload in a nonlinear fragment backed by a splice-imported page, which the attacker arranges with splice() and vmsplice() style plumbing on the sending side.

No user interaction and no remote access are required, and the write is deterministic once the layout is arranged rather than a race that must be won repeatedly. The primitive is strong: a controlled write into a page shared with a file or another process, which leads to file corruption, cross-process memory corruption, use-after-free, and local privilege escalation. In virtualized and containerized hosts the shared-page angle is what makes the scope changed, since corruption can cross a tenant boundary.

Discovery

The public record does not credit an outside researcher. The flaw record was created in Red Hat's tracker on 2026-06-05, with analysis by Red Hat's Rohit Keshri, ahead of the coordinated 2026-06-25 publication and the release of backports across every supported stable tree on the same day. Both the Red Hat write-up and the upstream commit message describe the splice-imported-page scenario in detail, which suggests the reporter demonstrated it rather than merely theorized it.

Exploitation Context

CISA added CVE-2026-53266 to the Known Exploited Vulnerabilities catalog on 2026-09-18, roughly three months after the fix, alongside two other Linux kernel bugs. CISA published no indicators or actor attribution, and vendor databases still record no verified public exploit code, so the exploitation evidence sits with CISA and its reporting partners rather than in open sources. EPSS rated it at about 0.1 percent before the listing, which is the usual disconnect between public-chatter modeling and targeted operational use.

It is worth noting that this CVE and CVE-2025-39682, listed on the same day, both turn on pages imported into socket buffers by splice(). That is not a coincidence so much as a sign of where kernel exploitation research is currently concentrated: the zero-copy paths, where page ownership assumptions made by one subsystem are violated by another.

Exposure is not internet-measurable. The at-risk population is Linux hosts running bridges with ebtables SNAT rules, which in practice means hypervisors, container hosts, and network appliances, weighted toward the long-lived infrastructure that patches least often.

Remediation

1. Patch to a fixed kernel: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13, or 7.1 and later. On Red Hat Enterprise Linux apply RHSA-2026:36645 for RHEL 9 and RHSA-2026:39082 or RHSA-2026:39083 for RHEL 8. On other distributions apply the erratum that names this CVE.
2. Reboot onto the patched kernel, or apply a livepatch if your vendor ships one for this CVE.
3. Until patched, remove the exposure directly: audit ebtables -t nat -L for snat rules using the ARP rewrite option and drop the ones you do not need. Where the bridge NAT path is unused entirely, blacklist ebtable_nat and ebt_snat in modprobe configuration so they cannot autoload.
4. Tighten who can reach the path. Do not grant NET_ADMIN to containers that do not require it, and consider disabling unprivileged user namespaces (kernel.unprivileged_userns_clone=0 or the equivalent sysctl on your distribution) on hosts where no workload needs them.
5. Isolate hypervisor and container-host management planes from untrusted tenants, and treat any host where a tenant holds NET_ADMIN in a shared network namespace as directly exposed.
6. Review logs for kernel oopses or warnings in ebt_snat, skb_store_bits, or the bridge netfilter path, and for unexplained file corruption on hosts running bridges, which is the distinctive symptom of this bug. Federal civilian executive branch agencies must remediate by 2026-09-21 under CISA BOD 26-04.