CVE-2026-53266

What it actually does

This Linux kernel flaw affects the bridge netfilter ebtables SNAT path when ARP sender hardware address rewriting is enabled. The kernel safely checked readability of the ARP header but did not ensure that the ARP sender hardware address bytes were writable before calling skb_store_bits(). Under specific conditions involving a nonlinear socket buffer whose fragment is backed by a splice-imported file page, the kernel could write the rewritten MAC address directly into that backing page instead of a private writable packet buffer. The practical technical impact is unintended kernel-mediated modification of shared or file-backed memory/page-cache contents, with potential data corruption and, depending on exploitability in a given kernel and configuration, possible privilege-boundary impact through corruption of files or memory used by other processes.

Why it matters to the business

Systems using Linux bridge filtering with ebtables SNAT rules that rewrite ARP sender hardware addresses may be exposed to integrity risk and operational instability. Successful exploitation could corrupt data, interfere with network bridging behavior, or create hard-to-diagnose failures in hosts that perform container networking, virtualization bridging, network appliances, or transparent firewalling. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is lower than for actively exploited kernel flaws; however, kernel memory and page-cache corruption issues should still be remediated during the next controlled kernel maintenance cycle, especially on multi-tenant or network-edge Linux bridge systems.

How an attack unfolds

An attacker must reach a vulnerable code path where a Linux host processes ARP traffic through bridge ebtables SNAT with ARP sender hardware address rewriting enabled. The attacker then causes or supplies an ARP packet represented internally as a nonlinear skb where the ARP sender hardware address range resides in a fragment that is not safely writable, such as one backed by a splice-imported file page. When the bridge netfilter SNAT target handles the packet, it reads the ARP header successfully and then rewrites the sender hardware address. Because the vulnerable kernel did not first force that byte range into writable packet memory, skb_store_bits() may copy the new MAC address into the underlying fragment page. The result is corruption of data outside the intended packet buffer. Exploitation is configuration-dependent and likely requires either local capability to generate the relevant skb shape or a system role where attacker-controlled traffic traverses vulnerable bridge ebtables rules.

How to fix it

Apply a kernel update from the Linux distribution or kernel vendor that includes the fix for the netfilter bridge ebt_snat ARP rewrite writability check. The specific upstream fix ensures the ARP sender hardware address range is writable before the ARP header is read and before skb_store_bits() rewrites the address. No exact fixed package versions were provided, so use vendor advisories and changelogs to identify kernels containing the patch titled "netfilter: bridge: make ebt_snat ARP rewrite writable" or equivalent. If immediate patching is not possible, reduce exposure by removing or disabling ebtables SNAT rules that rewrite ARP sender hardware addresses, migrating bridge NAT policy to a fixed kernel-supported path where appropriate, limiting untrusted local users' ability to create raw/splice-based packet flows, and restricting untrusted traffic from traversing bridge configurations that depend on ARP SNAT rewriting. Reboot into the updated kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the ebt_snat ARP writable-range fix. Review vendor changelogs, package metadata, or kernel source patches for the commit message "netfilter: bridge: make ebt_snat ARP rewrite writable". Inventory bridge ebtables NAT rules with commands such as ebtables-save, ebtables -t nat -L, and nft/bridge rule reviews where compatibility layers are used, and verify that ARP SNAT rewrite rules are removed or running only on fixed kernels. Validate that hosts have rebooted into the corrected kernel with uname -a or distribution package tooling. For exposure validation, check whether the bridge, br_netfilter, ebtables, and ebt_snat functionality is loaded or in use, and whether ARP sender hardware address rewriting is configured. Regression testing should include ARP traffic through bridge NAT rules to confirm normal forwarding behavior after the update.

Typical attack path

1. Identify a Linux system acting as a bridge, transparent firewall, virtualization/container bridge, or network appliance using ebtables bridge NAT.
2. Confirm that an ebtables SNAT rule rewrites ARP sender hardware addresses, commonly via an ARP-related SNAT option.
3. Generate ARP traffic that traverses the vulnerable bridge ebtables hook and matches the SNAT rule.
4. Arrange for the packet data to be represented as a nonlinear skb with the ARP sender hardware address bytes in a fragment that is not writable, such as a splice-imported file-backed page.
5. Trigger the SNAT ARP rewrite so the kernel writes the replacement MAC address into the backing fragment rather than a safe packet buffer.
6. Leverage the resulting unintended data corruption for denial of service, data integrity impact, or further exploit development depending on local kernel behavior and attacker privileges.

How to detect it

There is no reliable single log entry that proves exploitation, because the vulnerable operation is a low-level packet-buffer write that may silently corrupt a backing page. Start by identifying exposed systems: collect ebtables-save output, bridge configuration, loaded kernel modules, running kernel versions, and package changelogs. Look for ebtables bridge NAT SNAT rules that rewrite ARP sender hardware addresses, especially on hosts with container or VM bridges. For possible prior exploitation, review kernel logs and persistent journals for kernel oopses, BUG/WARN messages, page-cache or filesystem corruption reports, unexplained process crashes, bridge/netfilter warnings, and anomalies around ARP traffic handling. On high-risk systems, compare integrity of important local files against package-manager verification, file integrity monitoring, golden images, or backups, because the bug may manifest as unexpected file/page-cache modification rather than a clear network intrusion indicator. Network telemetry may show unusual bursts of ARP frames traversing bridge interfaces, but such traffic is not specific enough to confirm exploitation. If local threat activity is suspected, also review audit logs for untrusted processes using raw packet sockets, splice-heavy file-to-socket operations, or changes to ebtables rules.

• ebt_snat
• --snat-arp
• ebtables -t nat
• ebtables-save
• BROUTING
• POSTROUTING
• PREROUTING
• br_netfilter
• bridge-nf
• skb_store_bits
• kernel: BUG:
• kernel: WARNING:
• kernel: general protection fault
• kernel: page allocation failure
• kernel: kernel NULL pointer dereference
• netfilter: bridge
• netfilter: ebtables

What your security team should do

• Prioritize patching Linux hosts that act as bridges, transparent firewalls, container/VM networking nodes, or network appliances using ebtables bridge NAT.
• Inventory ebtables NAT rules and identify any SNAT rules that include ARP sender hardware address rewriting; treat those systems as the highest exposure group.
• If patching must be delayed, remove or disable ARP SNAT rewriting rules and restrict untrusted traffic paths through affected bridges.
• Reboot systems after kernel updates and verify the running kernel contains the fix, since stale running kernels remain vulnerable.
• Monitor kernel logs for page-cache corruption symptoms, kernel warnings, bridge/netfilter errors, unexpected ARP rewriting behavior, or crashes on systems that were exposed before patching.
• Because there is no known KEV listing or mature public exploit in the provided data, handle this as a targeted configuration-dependent kernel integrity issue rather than an internet-wide emergency, while still patching promptly in multi-tenant and network-edge roles.