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

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do every Debian suite, Proxmox VE 9’s default kernel, every tracked NixOS ref, Rocky Linux / RHEL 10, 9 and 8, and all three Amazon Linux 2023 kernel streams. The remaining gaps are end-of-life kernels that will never be fixed — Proxmox VE 8 (upgrade to Proxmox VE 9) — and any host that has not rebooted onto a fixed kernel.

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, and Rocky Linux / RHEL 10 followed in September. 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 when this tracker was archived: Proxmox VE 8 (end of life, no fix coming) 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, 9, and 10, every tracked NixOS channel, and Proxmox VE 9 have shipped it; Proxmox VE 8 is permanently Vulnerable (end of life, no fix coming).

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 mainline in v7.1-rc7, through the netfilter tree, and one coordinated stable batch carried it to every maintained line. The 7.1.y and 7.2.y branches were cut after it landed, so every release on them carries it.

7.0.y went end of life after the fix. Its final release, 7.0.14, is fixed; only 7.0.0 through 7.0.12 are exposed.

Old 5.4, 5.8 and 5.9 kernels are also in-window. The introducing commit was backported to them in 2020 (from 5.4.73, 5.8.17 and 5.9.2). All three are long past end of life upstream — a host still on one needs a supported kernel. Upstream kernels older than 5.4.73 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

forky is testing, the future Debian 14. The bookworm-backports 6.12 kernel carries the fix as well.

bullseye (Debian 11) left security support on 2026-08-31. Its last LTS kernels did carry the fix (DLA-4664-1 for linux, DLA-4671-1 for the opt-in linux-6.1), but nothing further will ship for it — move to bookworm or trixie.

The ebt_snat module is built and autoloaded on demand on every Debian kernel, and nothing in the default configuration blocks it. Debian kernels also 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 picked up the fix silently, in a rebase onto Ubuntu’s fixed resolute kernel, with no CVE-named changelog line. A PVE 9 host is patched once it has rebooted onto a fixed build.

• PVE 8 reached end of life in August 2026, before any fix reached its kernels. Its default proxmox-kernel-6.8 and its opt-in series stay vulnerable, and no fix is coming — upgrade to PVE 9.
• Superseded and preview series that PVE 9 still publishes, proxmox-kernel-6.17 and proxmox-kernel-6.14, stopped updating before the fix existed and will never get it. A host booting one should switch to the default kernel.

Proxmox hosts are 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 container’s capability set and 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 don’t assume either way — check with the Detection commands.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix. A host that overrides boot.kernelPackages is fixed too: linux_6_12, linux_6_6, linux_6_1, linux_5_15 and linux_5_10 are all past their first fix, and NixOS pins nothing older than 5.10.

Kernel updates land on nixpkgs master first and reach each channel once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) run a reduced jobset and pick up kernel updates fastest.

Which ref a flake input follows:

• github:NixOS/nixpkgs/nixos-unstable and github:NixOS/nixpkgs/nixos-26.05 follow those channels — the GitHub channel branches are updated to exactly the published channel pins.
• A bare github:NixOS/nixpkgs with no ref follows master, and github:NixOS/nixpkgs/release-26.05 follows that branch. Both are ungated development branches — they carry a kernel bump as soon as it lands, often a day or more before a channel publishes it.
• A bare nixpkgs registry input resolves by default to the nixpkgs-unstable channel: a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

Red Hat rates this CVE Important. Rocky 8, 9 and 10 each skipped the exact RHSA build and shipped the next one, which is where their fix starts.

• RHEL 7 ELS: fixed by RHSA-2026:71687 (kernel-rt RHSA-2026:71657). Rocky ships no EL7.
• RHEL 6: listed as affected in Red Hat’s record, with no fix.
• kernel-rt: RHEL 8’s is fixed by RHSA-2026:39082; RHEL 9’s and 10’s are fixed in the same advisories as their base kernels.

AlmaLinux 9 shipped ALSA-2026:36645. AlmaLinux, CloudLinux and Oracle Linux’s Red Hat Compatible Kernel rebuild RHEL’s kernel, so they get the fix as they rebuild Red Hat’s advisories.

Amazon Linux

The three AL2023 streams are the default kernel package (6.1 line) and the opt-in kernel6.12 and kernel6.18 packages; each was fixed by a cherry-pick in July.

Amazon Linux 2 reached end of support on 2026-06-30, a week after the CVE was published, with no fixed kernel. Every AL2 kernel stays vulnerable — 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 was started. 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 Ubuntu’s own focal/jammy/noble kernels, still waiting when this tracker was archived, and Proxmox VE 8, which is end of life and will never get it.
• 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