CVE-2026-53266 — Linux ebtables SNAT ARP-rewrite page-cache write

Summary

⚠️ This is a June bug that CISA flagged in September. The fix has been in every maintained upstream line since 2026-06-19, and by late July every Debian suite, all three Amazon Linux 2023 kernel streams, RHEL 8 and 9 (so Rocky and AlmaLinux), and every tracked NixOS channel had shipped it; Proxmox VE 9 followed in August. On 2026-09-18 CISA added it to the Known Exploited Vulnerabilities catalogue with a three-day federal deadline, which means someone is using it. Still vulnerable at the time of writing: Proxmox VE 8 (Ubuntu’s 6.8 fix is still pending), the Rocky Linux / RHEL 10 line (Red Hat lists no fix), and Ubuntu’s own focal, jammy, and noble kernels. Everywhere else the question is not whether a fix exists but whether the host has rebooted onto a kernel past its line’s First fixed — a machine patched in July and never rebooted is still running the vulnerable code.

How the exploitation chain works

The ebtables snat target rewrites the Ethernet source address of frames leaving a bridge, and — with --snat-arp — also the sender hardware address inside ARP packets, so that ARP replies advertise the rewritten MAC. The Ethernet rewrite is guarded by skb_ensure_writable(skb, 0). That looks odd but is deliberate: at the bridge hooks the Ethernet header is addressed through eth_hdr() while skb->data already points at the payload, so asking for ETH_HLEN writable bytes would test the payload, not the header, and would reintroduce the short-frame drops that 63137bc5882a fixed in v5.10.

The ARP rewrite is a different case. It writes through skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) at an offset relative to skb->data — into the payload proper — but the only check before it was skb_header_pointer(), which guarantees the ARP header can be read, not that the bytes after it can be written. If the sender-hardware-address range lives in a non-linear fragment, skb_store_bits() maps that fragment’s page and copies the six MAC bytes straight into it.

Normally that page is the kernel’s own receive buffer and the copy is exactly the intended rewrite. But a socket buffer can also carry pages the kernel does not own outright — the commit names the case: a fragment “backed by a splice-imported file page”, meaning a page-cache page of a file that splice() attached to the socket’s send path by reference, without copying. A frame whose ARP payload is backed by such a page reaches the snat rule with the file page still attached, and the rewrite writes the MAC bytes into the file’s cached contents. The commit stops there. What that primitive is worth is inference from Dirty Pipe (CVE-2022-0847), which was the same thing — a write into a page-cache page the writer had no permission to modify: a few controlled bytes at a chosen offset in a readable setuid binary or shared library are enough to run code as root. No public code demonstrates that chain for this bug, but it is the obvious use of the write, and CISA’s listing says the bug has been used.

The fix, 67ba971ae025, adds a single guard on the --snat-arp path: skb_ensure_writable(skb, sizeof(struct arphdr) + ETH_ALEN) before the ARP header is read and before skb_store_bits() runs, which makes the kernel copy any shared or read-only backing into a private buffer first. It is three lines in ebt_snat_tg(), and the stable backports are byte-identical.

ℹ️ The write only escapes when the packet is the attacker’s. A frame received from the wire lives in kernel-owned pages and the ARP rewrite does what it always did, so remote ARP traffic on its own cannot trigger anything — the kernel CNA scores it AV:L for that reason. The dangerous case needs a local sender who controls the rule (CAP_NET_ADMIN over the bridge’s namespace) and the packet’s backing pages. Where unprivileged user namespaces are enabled, any local user can build that setup in a private namespace; where they are disabled, it takes a container or process that already holds CAP_NET_ADMIN. None of this changes a row’s verdict — only the 67ba971ae025 backport does — but it decides who on a given host can reach the bug.

Vulnerable commit range

The reachable lifetime is therefore 5.10 through 7.0.12 (and 7.1 before -rc7), plus the long-dead 5.4.y / 5.8.y / 5.9.y lines from the point release that took the introducing commit. A kernel is safe by carrying the fix, or by predating v5.10 (and 5.4.73) altogether.

Patch status

A row is Fixed only if its kernel carries the 67ba971ae025 fix — a release at or past its branch’s first-fixed version, or an explicit distro backport. The upstream picture has been complete since 2026-06-19: mainline carries the fix from v7.1-rc7, the 7.1.y and 7.2.y stable branches were cut after it landed and so have carried it from their first release, and the same-day 7.0.13, 6.18.36, 6.12.94, 6.6.143, 6.1.176, 5.15.210, and 5.10.259 point releases covered every longterm line. Downstream, every Debian suite, all three Amazon Linux 2023 kernel streams, RHEL/Rocky 8 and 9, every tracked NixOS channel, and Proxmox VE 9 have shipped it; Proxmox VE 8 and Rocky Linux / RHEL 10 remain Vulnerable.

The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. Current kernel is what each release ships today; First fixed and Fixed since record the build that first carried the fix and the date it shipped, and stay — until a row is fixed.

Linux kernel

The fix reached Linus in v7.1-rc7 (tagged 2026-06-07) through the netfilter tree, two weeks after it was written, and twelve days later a single coordinated stable batch on 2026-06-19 carried it to every line kernel.org maintained: 7.0.13, 6.18.36, 6.12.94, 6.6.143, 6.1.176, 5.15.210, and 5.10.259, each the same three-line change by subject. The 7.1.y stable branch started from v7.1 (2026-06-14), after the fix, so every 7.1 release carries it; the line has since reached end of life at 7.1.13, but a host pinned to it stays fixed. The 7.2.y branch was likewise cut from v7.2 (2026-08-16) with the fix already in. The 7.0.y line is the one that went end of life after the fix: its final release, 7.0.14 (2026-06-27), is fixed, and only 7.0.0 through 7.0.12 are exposed.

The introducing commit was also backported in 2020 to the 5.4, 5.8, and 5.9 stable lines (from 5.4.73, 5.8.17, and 5.9.2), so a vendor kernel on one of those series is in-window too; all three are long past end of life upstream and get no rows here, and the only way out for a host still on one is a supported kernel. Kernels older than 5.4.73 — including the RHEL 6 and 7 series — are not affected.

To check a tree directly: a fixed ebt_snat_tg() (in net/bridge/netfilter/ebt_snat.c) calls skb_ensure_writable(skb, sizeof(_ah) + ETH_ALEN) inside the --snat-arp branch, before skb_header_pointer(); an unfixed one goes from skb_header_pointer() straight to skb_store_bits().

Debian

Every Debian suite is fixed, and was within a month of the upstream fix. sid picked up the 7.0 line’s first-fixed release as 7.0.13-1 on 2026-06-19, the day the stable release came out, and testing (forky, the future Debian 14) migrated the same upload on 2026-06-28; both have since moved on to the 7.1 and 7.2 lines, which were cut with the fix already in. trixie (Debian 13, the 6.12 line) shipped its line’s first-fixed release, 6.12.94-1, through trixie-security on 2026-06-21. bookworm (Debian 12, the 6.1 line, now in LTS) got 6.1.176-1 — its line’s first-fixed release — as DLA-4665-1 on 2026-07-03, and the bookworm-backports 6.12 kernel has been at or past 6.12.94-1~bpo12+1 since 2026-06-23.

bullseye (Debian 11) left Debian’s security support on 2026-08-31 and is not tracked. Its last LTS kernels did carry the fix (DLA-4664-1 for linux, DLA-4671-1 for the opt-in linux-6.1, both early July), but nothing further will ever ship for it; a host still on bullseye should move to bookworm or trixie.

The ebt_snat module is built and autoloaded on demand on every Debian kernel (modinfo on a trixie host shows the .ko); nothing in the default configuration blocks it, and Debian kernels enable unprivileged user namespaces by default (kernel.unprivileged_userns_clone=1), so the local path is open on any host with an in-window kernel.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over. PVE 9’s default proxmox-kernel-7.0 is fixed: Ubuntu shipped the fix in its resolute kernel 7.0.0-31.31, and the 7.0.14-9 packaging build (changelog dated 2026-08-05) rebased onto exactly that Ubuntu source — a silent fix inside a routine rebase, with no CVE-named changelog line — and every later build, including the 7.0.14-17 currently in pve-no-subscription, inherits it. A PVE 9 host that has rebooted onto 7.0.14-9-pve or newer is patched.

PVE 8’s default proxmox-kernel-6.8 is still vulnerable. Its packaging is based on Ubuntu’s 6.8.0-136.136 with fixes picked from 6.8.0-139.139, neither of which carries this change; Ubuntu’s own tracker has the noble 6.8 fix pending in 6.8.0-146.146, a build not yet published, and the PVE packaging branch carries no ebt_snat cherry-pick. The fix will arrive either when Proxmox rebases onto a fixed Ubuntu 6.8 build or as a named cherry-pick.

Both releases also still publish superseded and preview kernel series that Proxmox stopped updating before the fix existed and that will never receive it: PVE 9’s proxmox-kernel-6.17 (last built July 2026, on an Ubuntu 6.17 source Ubuntu itself still marks unfixed) and -6.14 (May 2026), and PVE 8’s -6.14, -6.11, and -6.5. A host booting any of them stays vulnerable until it switches to its release’s current default kernel — which on PVE 8 is itself still waiting for a fix.

Proxmox hosts are also the natural home of this bug’s preconditions: every VM and container sits behind a Linux bridge, and an unprivileged LXC container is a network namespace with its own bridge port. Whether an ordinary user or a container can reach the write depends on the host’s user-namespace settings — PVE runs Ubuntu kernels on a Debian userland, and Ubuntu’s 6.8 and 7.0 kernels carry their own AppArmor restriction on unprivileged user namespaces, so do not assume either way — and on the container’s capability set. Check with the Detection commands.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, and both the nixpkgs master and release-26.05 branches bumped it to the line’s first-fixed release, 6.18.36, on 2026-06-19 — the day it was tagged. The channels republished it over the following week: nixos-unstable-small and nixos-26.05-small on 2026-06-20, nixpkgs-unstable and nixos-26.05 on 2026-06-23, and nixos-unstable — gated on the full NixOS jobset and usually last — on 2026-06-26. Every tracked NixOS ref has been fixed since then. Kernel updates land on master and release-26.05 first, and each channel republishes them once its Hydra jobset passes; the -small channels are gated on a reduced jobset and typically lead their siblings, while the nixpkgs-unstable channel — what a bare nixpkgs flake registry input resolves to — is a separate channel aimed at non-NixOS Nix users.

A host that overrides boot.kernelPackages to another series is fixed as long as that series is at or past its own first-fixed release (the linux_6_12, linux_6_6, linux_6_1, linux_5_15, and linux_5_10 packages all are); NixOS pins nothing older than 5.10.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks, and Red Hat’s record for this CVE (CSAF/VEX, initial release 2026-06-01, the day the fix was committed to the public netfilter tree) rates it Important. Red Hat shipped the fix for RHEL 9 as RHSA-2026:36645 on 2026-07-08 (kernel-5.14.0-687.23.1.el9_8) and for RHEL 8 as RHSA-2026:39083 on 2026-07-14 (kernel-4.18.0-553.143.1.el8_10, with RHSA-2026:39082 for the real-time kernel-rt). Rocky rebuilds RHEL unchanged: its 9 and 8 mirrors did not publish those exact builds but went straight to the next ones, 5.14.0-687.24.1.el9_8 on 2026-07-10 and 4.18.0-553.144.1.el8_10 on 2026-07-14, so both rows are fixed from those builds on. AlmaLinux 9 shipped ALSA-2026:36645 on 2026-07-08.

RHEL 10 has no fix. Red Hat’s record lists the RHEL 10 kernel as Affected with no fix available and no RHSA — the 6.12-based EL10 kernel is in-window, and no erratum has shipped in the three months since the upstream fix — so the Rocky Linux 10 row stays vulnerable, and a Rocky 10 host should rely on the mitigations below. Red Hat’s published workaround is the same as the one here: drop the ARP rewrite from ebtables SNAT rules, or remove SNAT rules matching ARP on bridges. Oracle Linux and CloudLinux track the RHEL determination.

RHEL 6 and RHEL 7 are not affected — their 2.6.32 and 3.10 kernels predate the introducing commit, and Red Hat records them vulnerable_code_not_present. Both are end of life and out of scope here. The niche kernel-rt real-time kernel shares the base kernel’s status on each release.

Amazon Linux

Amazon fixed all three AL2023 kernel streams in July, each with a cherry-pick that made the stream’s build the line’s first-fixed release: ALAS2023-2026-1924 (2026-07-06) in the default kernel stream at 6.1.176-220.358.amzn2023, ALAS2023-2026-1925 (2026-07-06) in the kernel6.18 opt-in stream at 6.18.36-69.134.amzn2023, and ALAS2023-2026-1968 (2026-07-20) in the kernel6.12 opt-in stream at 6.12.94-123.174.amzn2023. All three are fixed. Amazon Linux 2 reached end of support on 2026-06-30, a week after the CVE was published and with no fixed kernel; every AL2 kernel is permanently vulnerable, and the only way out is AL2023.

Detection

Is the running kernel in the affected window and missing the fix? Every kernel from 5.10 (and 5.4.73) up to the fixed releases is in-window. Compare the running kernel against the Patch status table’s First fixed column for its series; a distro kernel below its line’s first-fixed build, or one that has been patched but not rebooted, is still vulnerable:

uname -r

Is an ARP-rewriting SNAT rule in place? The bug is only reachable through an ebtables snat target with --snat-arp. List the bridge NAT table (the ebtables command is the nftables-backed compatibility tool on current systems; a rule created through native nft shows up in the bridge family ruleset instead):

ebtables -t nat -L

nft list ruleset bridge

Is the module present? modinfo prints the on-disk path of the ebt_snat module, or an error if the kernel has no such module — but a present module is loaded on demand the moment a rule needs it, so this tells you whether the path can be reached, not whether it is:

modinfo -F filename ebt_snat

Can an unprivileged user reach CAP_NET_ADMIN? The local path in a private namespace needs unprivileged user namespaces. If both of these are non-zero, an ordinary user can unshare -Urn into a namespace where it holds CAP_NET_ADMIN over its own bridge:

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces

Is this a multi-tenant or container host? Any container that holds CAP_NET_ADMIN (for example one run with --cap-add=NET_ADMIN or a privileged pod) can insert ebtables rules on a bridge it owns, regardless of the user-namespace sysctls:

grep -rEl 'CAP_NET_ADMIN|NET_ADMIN|privileged' /etc/containers /etc/kubernetes 2>/dev/null

Public PoC

There is no public exploit for this CVE at the time of writing: no PoC repository, no write-up, and no vendor advisory that names a campaign. What exists publicly is the fix commit, whose description spells out the primitive — a controlled write into a splice-imported file page — and Red Hat’s assessment that it is a local privilege escalation. CISA’s KEV entry on 2026-09-18 says the bug has been exploited in the wild, and its three-day deadline and forensic-triage flag signal that this was not a marginal report. Treat the absence of public code as no reproducer to test with, not as no exploit: the primitive class is well understood from Dirty Pipe, and an attacker who can reach the write does not need this page to finish the chain.

Mitigation

The real fix is a patched kernel (a release at or past its line’s First fixed, or a distro backport of 67ba971ae025), followed by a reboot — a kernel package installed in July but never booted protects nothing. Until then the exposure can be narrowed; none of these is a fix.

Remove the ARP rewrite from SNAT rules

The vulnerable path is only the --snat-arp option of the snat target. Where a bridge’s SNAT rules do not need ARP rewriting — which is most of them; the option exists for bridges that hide the real MAC from the far side — drop it, or remove SNAT rules that match ARP at all. This is Red Hat’s published workaround, and it closes the bug for rules the administrator controls. It does nothing about a rule an attacker inserts in a namespace of their own.

Block the ebt_snat module

Where bridge NAT is not used at all, blocking the module removes the datapath for every caller, including a namespaced or containerised one that would otherwise autoload it. install … /bin/false is surer than a plain blacklist, which only suppresses alias autoloading:

printf 'install ebt_snat /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-53266.conf

That rule only prevents future loading — it does not remove a module already resident. Where the module is loaded but no rule uses it, unload it so the block takes effect now:

sudo modprobe -r ebt_snat

A module that is genuinely in use cannot be unloaded, and on a host whose bridges rely on SNAT you could not block it without breaking that service — there the first mitigation applies instead. It is likewise inert if the target is built into the kernel (=y) rather than loadable; the modinfo check above prints a .ko path only for a loadable module. Proxmox VE and most container hosts do use ebtables or its nftables equivalent for bridge filtering; check before blocking.

Restrict unprivileged user namespaces

The local path for an ordinary user depends on user namespaces to obtain CAP_NET_ADMIN over a private bridge. Where unprivileged user namespaces are not needed, disabling them closes that path (it does not stop a process or container that already holds CAP_NET_ADMIN). On Debian/Ubuntu kernels:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Persist it across reboots:

echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cve-2026-53266.conf

On kernels without that Debian/Ubuntu knob, cap the count instead:

sudo sysctl -w user.max_user_namespaces=0

Restrict who holds CAP_NET_ADMIN

On multi-tenant and container hosts, review which workloads are granted CAP_NET_ADMIN: drop it from container capability sets that do not need it, avoid privileged containers, and keep untrusted workloads out of namespaces where they can manage a bridge. This shrinks the reachable surface but leaves a trusted-but-hostile caller in scope.

Risk notes

• Exploited in the wild, three months after the fix. CISA’s KEV listing (2026-09-18, due 2026-09-21) is the reason this tracker exists. The window between fix and listing means the population at risk is not “distros that have not patched” but hosts that have not rebooted onto a June-or-later kernel, plus the few lines still waiting: Proxmox VE 8, RHEL/Rocky 10, and Ubuntu focal/jammy/noble.
• The primitive is a page-cache write, not a heap bug. Like Dirty Pipe, it corrupts a file’s cached contents with no write permission on the file. That makes it unusually reliable for privilege escalation once reached — no race, no heap grooming — which is presumably why it was worth exploiting despite the setup it needs.
• Multi-tenant and container hosts are the exposure. Reaching the write takes CAP_NET_ADMIN over a bridge plus a locally crafted packet. Any host where an unprivileged user can create namespaces, or where a container holds NET_ADMIN, is in scope; a single-user workstation running trusted code is not meaningfully exposed even while unpatched.
• No “module not present” escape. ebt_snat is a loadable module (verified on Debian; other distributions build the ebtables targets the same way, though EL may ship them in a separate package) that autoloads when a rule needs it; unless it is explicitly blocked, its absence from lsmod means nothing.
• Backports available (CVE-2026-53266): the fix has landed in mainline (7.1-rc7) and in 7.0.13, 6.18.36, 6.12.94, 6.6.143, 6.1.176, 5.15.210, and 5.10.259; distro kernels that have not adopted one of those, or cherry-picked the fix, remain vulnerable.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the git reference, advisory, or repository index that established each fact — so any row can be audited or reproduced. Most readers never need it.

References