netfilter: bridge: make ebt_snat ARP rewrite writable
Affects Linux kernels from commit 63137bc5 onward, including stable ranges 5.4.73 to 5.5, 5.8.17 to 5.9 and 5.9.2 to 5.10, only with the ebtables SNAT ARP sender MAC rewrite. No fixed release version is given in the checked facts.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Actively exploited
- Fix
- Fixed in 5.5, 5.9, 5.10
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's netfilter bridge ebtables SNAT target is affected, in its handling of ARP packets. A crafted packet whose ARP sender hardware address sits in a nonlinear buffer, such as a file page imported via splice, can have that memory modified in place, which could corrupt data that the kernel does not expect to change.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().
Timeline
- CVE published
- Added to CISA KEV
CISA has evidence of exploitation in the wild
- Record last updated
- CISA remediation deadline
Due date for US federal agencies to patch
Affected versions
- Linux Linux
From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in 76280b78cc9f23bdc6438e10ad6dff148ef8375b; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in b7e91939ba9be805a62a257fa4e227dffbb88fa0; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in afd64b59c3de9bbbdd3759e834fdc55cda716e0b; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in 153ea96c806aea395daba907a4f88480b6ad5093; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in b18675263db1147c8e1cab625400c13a0d87bd2d; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5; From 63137bc5882a1882c553d389fdeeeace86ee1741 · fixed in 67ba971ae02514d85818fe0c32549ab4bfa3bf49; From 5.4.73 · fixed in 5.5; From 5.8.17 · fixed in 5.9; From 5.9.2 · fixed in 5.10
- Linux Linux
5.10
References 8
git.kernel.org
- stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87
- stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b
- stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0
- stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b
- stable/c/153ea96c806aea395daba907a4f88480b6ad5093
- stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d
- stable/c/c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5
- stable/c/67ba971ae02514d85818fe0c32549ab4bfa3bf49
Questions about CVE-2026-53266
What does this mean?
The ebtables SNAT target can rewrite the ARP sender hardware address. When it does, the new MAC address is written directly into a file page that was imported with splice and sits in a nonlinear socket buffer fragment, skipping the check that the page is writable.Source: git.kernel.org
Am I affected, and how do I check?
The checked facts list Linux kernel ranges starting at commit 63137bc5882a1882c553d389fdeeeace86ee1741, plus stable ranges 5.4.73 to 5.5, 5.8.17 to 5.9 and 5.9.2 to 5.10. The bug needs the ebtables SNAT target with the optional ARP sender hardware address rewrite. To check, compare the running kernel with `uname -r` and look for SNAT rules with the ARP rewrite option in the ebtables nat table.Source: git.kernel.org
What should I do about it?
The checked facts do not name a fixed release, but they list fix commits for several stable branches. Check your distribution or kernel vendor for a kernel build that includes one of those commits for your branch.Source: git.kernel.org
Is it being exploited?
Yes. CISA added it to its Known Exploited Vulnerabilities catalog on 2026-09-18, which means it has evidence of attacks. No public exploit code is tracked.Source: cisa.gov, cve.now feed data