Patchfirst
CVE-2026-53266 KEVPublic exploit High · 8.8 EPSS 0.9%

Linux Kernel Out-of-Bounds Write Vulnerability

Linux · Kernel

Summary

The Linux kernel's netfilter bridge ebt_snat target has an out-of-bounds write flaw in its optional ARP sender hardware address rewrite, which writes through skb_store_bits() without first ensuring the target range is writable. An attacker with local access and low privileges can trigger this when the ARP sender hardware address sits in a nonlinear skb fragment backed by a splice-imported file page, causing the kernel to copy the new MAC address directly into that page, with no user interaction required.

Official description · NVD

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().

Breakdown
71.3 / 100
Exploited
Yes, in CISA KEV
Reports
0
Tactics
1/15

How an attack unfolds

Based on mappings. Select a step to see the evidence.
  1. How attackers get in

First seen exploited 3 months after disclosure. Public exploit code (PoC-in-GitHub) appeared 3 months after disclosure.

  1. Disclosedday 0
  2. First seen exploitedVulnCheck KEV evidenceAdded to CISA KEVEU database agrees+3 mo
  3. Public exploit codePoC-in-GitHub+3 mo

CISA KEV listing is when exploitation was confirmed, not necessarily the first attack.

techniques

1 , grouped by in kill-chain order, 1 cited passage 1

Privilege EscalationTA0004

Exploitation for Privilege Escalation T1068 Medium
AI mapping from the description · how it is exploited

local privilege use corrupts kernel memory via write

skb_store_bits() maps the frag page and copies the new MAC address
From the official description (NVD) Original (opens in a new tab) ↗

Detection

0 rules for this CVE · 31 general rules for its techniques

Rules for this CVE

0 that reference CVE-2026-53266 directly.

CVE-specific rules are not available in this build. Search SigmaHQ ↗

General rules for this CVE’s techniques

These detect the technique in general, not this specific vulnerability.

Sigma rules © SigmaHQ, Detection Rule License 1.1; linked, not reproduced.

What security researchers reported

Not named in any threat report yet

Also mentioned in 41 community threat pulses (AlienVault OTX)

Weaker evidence

Pulses are indicator collections that anyone can publish. A mention is not confirmation of exploitation.

References

9 links, grouped by NVD tag
↑ ↓ chooseEnter openEsc close