🌉 ebtables SNAT ARP Write Advisory

ebtables SNAT ARP bug: out-of-bounds write when rewriting the ARP sender address on a bridge
CVE-2026-53266     CVSS 8.8 High (NVD)     published June 25, 2026     Ubuntu priority: High     Red Hat: Important (CVSS 7.5)     On CISA's Known Exploited list since 2026-09-18

A bug in the kernel's bridge firewall (netfilter ebtables) target that rewrites source MAC addresses. When the rule also rewrites the ARP sender hardware address, the kernel can write the new address straight into a memory page that belongs to a file. A local attacker needs a machine where such a rule exists.
Versions and advisories below were checked on 2026-10-01 against the Ubuntu CVE tracker, Red Hat's CVE data and NVD (read through a summarising tool, so re-check a number against the vendor page before you rely on it). A kernel NEWER than the one listed also contains the fix. The Ubuntu page was last updated the same day, and several Ubuntu fixes are still "work in progress": re-check often.
Defensive notes only: no exploit code here. Only run the checks on machines you own or administer.
IMPORTANT: NVD's CISA fields list this CVE in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-18, due date 2026-09-21). Treat it as "being used in the wild".

The score NVD shows is 8.8, and it comes from the Linux kernel CNA (local, low privileges, changed scope, high impact); NVD has not added its own. Red Hat scores it 7.5 and describes the attacker as needing specific bridge rules, which makes it harder to reach. Both agree it is serious where the rules exist, and harmless-ish where they do not.

ebtables is the firewall for traffic on Linux network bridges (the software switches used by virtual machines and containers). Its SNAT target can rewrite the source MAC address of frames, and with an extra option it also rewrites the sender hardware address inside ARP packets.
The kernel keeps packet data in "socket buffers" (skb). Part of the packet can sit in a fragment that is backed by a page imported from a file with splice(). The fix's description says the old code wrote the new MAC address directly into that page without first making the range safely writable, so the write lands in memory that belongs to a file.
The fix makes the kernel ensure the ARP address range is writable before it reads the ARP header and before it calls skb_store_bits(). (My reading: this is the same broad kind of bug as Dirty Frag and Copy Fail, memory belonging to a file being modified through a networking path. The vendors' advisories do not draw that comparison themselves.)

Only machines where BOTH are true: the kernel has the ebtables SNAT target (module ebt_snat or the nftables equivalent), AND a rule on a bridge rewrites ARP sender hardware addresses. A local user must also be able to run code.
Ubuntu:          24.04, 22.04 and 20.04 kernels are affected. For 24.04 and 22.04 Ubuntu later showed a fix as prepared but NOT yet released (24.04: 6.8.0-146.146, 22.04: 5.15.0-198.208, as of 2026-10-01); 20.04 still had no fix. 26.04 is fixed. 18.04, 16.04 and 14.04 are not affected. 25.10 is end-of-life and ignored.
Red Hat family:  RHEL 8, 9 and 10 (plus EUS/E4S streams) have fixes. RHEL 6 and 7 ELS (extended life) also got fixes. The real-time kernel (kernel-rt) on RHEL 9 is still marked affected.
Others:          Debian, SUSE, Amazon Linux and rebuilds published their own advisories.
Lower risk:      machines with no bridge ebtables rules. Hosts doing bridge firewalling for virtual machines are the usual place to look.

Piece                What it is                                                                Notes
ebt_snat             the ebtables SNAT target (rewrites source MAC, optionally ARP sender MAC)   A loadable module; it loads when a rule uses it
ebtables / nftables  the tools that create bridge firewall rules                                  Modern systems often use ebtables-nft, which stores the rules in nftables
What breaks if you remove the rules: any bridge setup that really depends on source-MAC rewriting (some VM/NAT-on-bridge designs) will change behaviour. Check before you delete anything and keep a copy.

uname -r                                          # the kernel you are running RIGHT NOW (compare with the tables below)
lsmod | grep ebt_snat                             # is the SNAT target module loaded?
sudo ebtables -t nat -L 2>/dev/null | grep -i snat  # legacy ebtables: any SNAT rules in the nat table?
sudo ebtables-save 2>/dev/null | grep -i snat       # the same, as a restorable listing (works with ebtables-nft too)
sudo nft list tables | grep -i bridge             # nftables: do any bridge tables exist at all?
sudo nft list ruleset | grep -i 'saddr set'       # nftables: rules that set a source MAC address (read the context, not every hit is a problem)
If all of these come back empty, nothing on the box is using the affected path. Patch anyway because of the known-exploited status, but you are not exposed in the meantime.

Manual mitigation (as published by Red Hat; only if you cannot patch yet)
Red Hat: "Disable ARP hardware address rewriting in ebtables SNAT rules, or remove ebtables SNAT rules that operate on ARP traffic on bridge interfaces."
Ubuntu and the kernel project publish no workaround beyond the patch.
Typical steps:
1. Save the rules first, so you can restore them:
   sudo ebtables-save | sudo tee ~/ebtables-before-cve-2026-53266.txt
2. List the SNAT rules with line numbers, and find the ones that touch ARP (the ebtables option is --snat-arp):
   sudo ebtables -t nat -L --Lc --Ln | grep -i -B1 snat
3. Remove or change those rules (the exact command depends on how you created them, for example a script, libvirt, or a service). Using the rule's own definition:
   sudo ebtables -t nat -D POSTROUTING -j snat ... --snat-arp      (repeat your original rule with -D instead of -A, or delete by number: sudo ebtables -t nat -D POSTROUTING 1)
   Without --snat-arp, the rule rewrites only the Ethernet source address, which is outside the sentence Red Hat gives, but the flaw is described as being in the ARP rewrite path, so check with your vendor if you rely on such rules.
4. Make it permanent: fix the script or service that creates the rules, otherwise they come back at the next boot.
5. Verify:
   sudo ebtables-save | grep -i snat                           # no ARP-rewriting SNAT rules should remain
Extra (my addition, not a vendor-published step): if you do not use ebtables SNAT at all, you can also stop the module loading with
   echo "install ebt_snat /bin/false" | sudo tee /etc/modprobe.d/manual-disable-ebt_snat.conf
   sudo rmmod ebt_snat 2>/dev/null
and remove that file again after patching. Test first on anything that uses bridge firewalling.
Undo later: put the saved rules back with  sudo ebtables-restore < ~/ebtables-before-cve-2026-53266.txt  (only after you are running the patched kernel), and delete the modprobe block file.

Ubuntu:
   sudo apt update && sudo apt upgrade
   sudo reboot
Red Hat / RHEL:
   sudo dnf upgrade --refresh 'kernel*'
   sudo reboot
A kernel update does nothing until you boot into it. Run uname -r afterwards and compare with the tables below.
Ubuntu 24.04 and 22.04 users on the normal kernels: as of 2026-10-01 Ubuntu showed a fix as PREPARED (24.04: 6.8.0-146.146, 22.04: 5.15.0-198.208) but not yet released as a normal update. Until it is released, do the mitigation above, or move a 24.04 machine to the 7.0 HWE kernel (fixed version in the table), and check the tracker again every day or two.

Patched kernels: Ubuntu (first fixed versions; anything newer is also fixed)
Release              Kernel line              Fixed in
26.04 LTS Resolute   linux (7.0)              7.0.0-31.31
24.04 LTS Noble      linux-hwe-7.0            7.0.0-31.31~24.04.1
24.04 LTS Noble      linux (6.8 GA)           fix prepared, not yet released: 6.8.0-146.146
22.04 LTS Jammy      linux (5.15) and HWE     fix prepared, not yet released: 5.15.0-198.208
20.04 LTS Focal      linux (5.4)              vulnerable (Ubuntu Pro / ESM may deliver a fix)
18.04, 16.04, 14.04                           not affected
25.10 Questing                                end-of-life, no fix will come: upgrade
26.04 cloud and special kernels (first fixed):
   linux-aws 7.0.0-1012.12     linux-azure 7.0.0-1014.14     linux-gcp 7.0.0-1011.11     linux-oracle 7.0.0-1011.11     linux-gke 7.0.0-1006.7
   linux-ibm 7.0.0-1013.13     linux-nvidia 7.0.0-1018.18     linux-raspi 7.0.0-1019.19     linux-realtime 7.0.0-31.31.1     linux-riscv 7.0.0-31.31.1
   linux-oem-7.0 7.0.0-1013.13     24.04: linux-nvidia-7.0 7.0.0-1018.18~24.04.1     linux-nvidia-tegra 6.8.0-1035.38
Cloud kernels for 24.04, 22.04 and 20.04 were still vulnerable when checked: look them up on https://ubuntu.com/security/CVE-2026-53266.

Patched kernels: Red Hat Enterprise Linux (kernel package; "or newer" applies)
RHEL 10 (10.2)   6.12.0-211.59.1.el10_2    (RHSA-2026:71233, Sept 24 2026)
RHEL 10.0 EUS    6.12.0-55.106.1.el10_0    (RHSA-2026:71326, Sept 24 2026)
RHEL 9  (9.8)    5.14.0-687.23.1.el9_8     (RHSA-2026:36645, July 8 2026)
RHEL 9.6 EUS     5.14.0-570.143.1.el9_6    (RHSA-2026:71327, Sept 24 2026)
RHEL 9.4 E4S     5.14.0-427.152.1.el9_4    (RHSA-2026:71569, Sept 24 2026)
RHEL 9.2 E4S     5.14.0-284.194.1.el9_2    (RHSA-2026:71601, Sept 24 2026)
RHEL 8 (8.10)    4.18.0-553.143.1.el8_10   (RHSA-2026:39083, July 14 2026)
RHEL 8.8 TUS/E4S 4.18.0-477.169.1.el8_8    (RHSA-2026:71325, Sept 24 2026)
RHEL 8.6 AUS     4.18.0-372.217.1.el8_6    (RHSA-2026:70797, Sept 23 2026)
RHEL 8.4 AUS     4.18.0-305.209.1.el8_4    (RHSA-2026:71565, Sept 24 2026)
RHEL 7 ELS       3.10.0-1160.164.1.el7     (RHSA-2026:71687, Sept 24 2026)
RHEL 6 ELS       2.6.32-754.64.1.el6       (RHSA-2026:73732, Sept 30 2026)
Real-time kernels: RHEL 9 kernel-rt was still marked "Affected" when checked; RHEL 8 kernel-rt 4.18.0-553.143.1.rt7.484.el8_10 and RHEL 7 kernel-rt 3.10.0-1160.164.1.rt56.1316.el7 are fixed. NVIDIA for RHEL 10: 6.12.0-231.20.el10nv.
Rebuilds (AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux) use their own package numbers: follow their advisories, not this table.

Is my kernel patched?
Ubuntu:
   uname -r                                                         # compare with the Ubuntu table above
   apt changelog linux-image-$(uname -r) | grep CVE-2026-53266      # the changelog should mention the CVE
   pro fix CVE-2026-53266 --dry-run                                 # Ubuntu Pro client: says whether this machine is fixed
Red Hat / RHEL:
   uname -r                                                         # compare with the RHEL table above
   rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-53266      # the changelog should mention the CVE
   sudo dnf updateinfo list --cve CVE-2026-53266                    # which advisory fixes it and whether it is installed
   sudo needs-restarting -r                                         # says whether a reboot is still needed
Careful: rpm -q kernel and dpkg -l 'linux-image*' list INSTALLED kernels, including old ones you are not running. Only uname -r tells you what is actually running.

I removed the rule but it came back after a reboot: a script, libvirt, a firewall service or an nftables file recreates it. Fix the source, not just the live rules.
ebtables says "table does not exist" or prints nothing: you may have no bridge rules at all (good), or you use nftables directly: check sudo nft list ruleset.
Virtual machines lost network after deleting a rule: the rule was doing real work. Restore the saved file (ebtables-restore) and plan the patch instead.
Ubuntu 24.04 shows no released fix: on 2026-10-01 the fix was prepared (6.8.0-146.146) but not yet released. Mitigate, then run apt update again in a day or two (the live status card at the top of this page shows the current state).
I updated but uname -r shows the old kernel: you have not rebooted yet.

Do the "do I even have these rules?" check first. For most machines the answer is "no", and the job is then just patching on a short schedule.
Virtualization hosts and anything bridging VM traffic come first. A laptop with no bridge rules comes last.
Save the rules before you touch them. Firewall rules deleted from memory are a very quick way to learn what they were for.
Dirty Frag, Copy Fail and this one all come down to the same lesson: file pages and network buffers should not meet unsupervised.
Put the date and reason in a comment next to any change. A bridge that mysteriously behaves differently in six months is a bad mystery.
"Out-of-bounds write" is the kernel's polite way of saying the bytes went somewhere the author did not intend to host them.

Ubuntu CVE tracker:     https://ubuntu.com/security/CVE-2026-53266
Red Hat CVE page:       https://access.redhat.com/security/cve/cve-2026-53266
Red Hat CVE data feed:  https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-53266.json
NVD entry:              https://nvd.nist.gov/vuln/detail/CVE-2026-53266