Linux Kernel Netfilter Bridge ebt_snat ARP Rewrite Vulnerability (CVE-2026-53266)
Executive & SecOps Summary
SECOPS ASSESSMENTLinux systems utilizing ebtables SNAT targets within bridge netfilter configurations.
Local attackers can trigger kernel memory corruption, leading to Denial of Service (DoS) or Privilege Escalation.
Apply the latest kernel security patches provided by your distribution and reboot.
Affected Products & Version Scope
Remediation & Live Workaround Commands
PATCH & WORKAROUNDThe primary remediation is updating the Linux kernel to a patched version. Use your distribution's package manager to apply updates.
# For Ubuntu/Debian
sudo apt update && sudo apt upgrade linux-image-generic
# For RHEL/CentOS/Fedora
sudo dnf update kernel
# A system reboot is required to load the new kernel
sudo rebootAs a temporary workaround, audit and disable unnecessary ebtables SNAT rules:
ebtables -t nat -LBlock Kernel Privilege Escalation & Ransomware Payloads Before You Can Reboot
Protect unpatched Windows, Linux, and macOS workloads against in-memory exploitation and lateral movement with autonomous EDR.
Technical Root Cause & Exploitation Mechanics
The vulnerability exists in the ebt_snat target of the Linux kernel's ebtables implementation. When rewriting the ARP sender hardware address (SHA), the code fails to ensure the target memory range is writable before calling skb_store_bits(). If the packet data resides in a non-linear fragment backed by a read-only page (e.g., via splice-imported file pages), the kernel directly overwrites the page, leading to an Out-of-bounds Write (CWE-787). This flaw is listed in the CISA KEV catalog, indicating active exploitation or high risk of weaponization.
Official Vendor Advisories & References
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().
Subscribe to Daily Vulnerability Briefings & KEV Alerts
Concise morning briefings for SecOps, DevSecOps, and SRE teams covering newly exploited CVEs and mitigation priorities.