CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability

CISA Known Exploited Vulnerabilities

Name

Linux Kernel Out-of-Bounds Write Vulnerability

Vendor

Linux

Product

Kernel

Added to the catalog

2026-09-18

Due date for US federal agencies

2026-09-21

Weaknesses

CWE-787

Catalog version

2026.10.30

Linux Kernel contains an out-of-bounds write vulnerability in the ebtables SNAT target which allows an ARP sender hardware address rewrite to write directly into a nonlinear socket-buffer fragment backed by a splice-imported file page. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.

Required action (CISA)

Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Ransomware use: CISA does not mark known use of this vulnerability in ransomware campaigns.

Links in CISA's notes

• https://git.kernel.org/stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87
• https://git.kernel.org/stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b
• https://git.kernel.org/stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0
• https://git.kernel.org/stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b
• https://git.kernel.org/stable/c/153ea96c806aea395daba907a4f88480b6ad5093
• https://git.kernel.org/stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d
• https://git.kernel.org/stable/c/c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5
• https://git.kernel.org/stable/c/67ba971ae02514d85818fe0c32549ab4bfa3bf49
• https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
• https://nvd.nist.gov/vuln/detail/CVE-2026-53266

Read on 2026-11-02T23:39:54.475Z under licence cisa-kev-cc0@b0067899 from https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

NVD analysis

Status

Analyzed

Published

2026-06-25T09:16:44.643

Last modified

2026-09-19T04:17:53.580

Weaknesses

NVD-CWE-noinfo, CWE-787

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

References

• https://git.kernel.org/stable/c/153ea96c806aea395daba907a4f88480b6ad5093 (Patch)
• https://git.kernel.org/stable/c/67ba971ae02514d85818fe0c32549ab4bfa3bf49 (Patch)
• https://git.kernel.org/stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b (Patch)
• https://git.kernel.org/stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b (Patch)
• https://git.kernel.org/stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d (Patch)
• https://git.kernel.org/stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0 (Patch)
• https://git.kernel.org/stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87 (Patch)
• https://git.kernel.org/stable/c/c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5 (Patch)
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-53266 (US Government Resource)

This product uses the NVD API but is not endorsed or certified by the NVD.

Read on 2026-11-02T23:42:31.494Z under licence nvd-api-terms-of-use@ff2a5288 from https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-53266

CVE record

Title (CNA)

netfilter: bridge: make ebt_snat ARP rewrite writable

Assigner

Linux

State

PUBLISHED

Published

2026-06-25T08:39:53.190Z

Updated

2026-09-19T03:56:22.274Z

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

References

• https://git.kernel.org/stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87
• https://git.kernel.org/stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b
• https://git.kernel.org/stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0
• https://git.kernel.org/stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b
• https://git.kernel.org/stable/c/153ea96c806aea395daba907a4f88480b6ad5093
• https://git.kernel.org/stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d
• https://git.kernel.org/stable/c/c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5
• https://git.kernel.org/stable/c/67ba971ae02514d85818fe0c32549ab4bfa3bf49

Read on 2026-11-03T02:20:29.830Z under licence cve-terms-of-use@81bfa2f3 from https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/53xxx/CVE-2026-53266.json

Defensive techniques (MITRE D3FEND)

D3FEND maps these defensive techniques to the weakness (CWE) that NVD lists for this CVE, through the digital artifacts the weakness affects. D3FEND does not say they stop this vulnerability.

MITRE D3FEND™ knowledge graph. © 2025 The MITRE Corporation.
"The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use D3FEND for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy." Terms: https://d3fend.mitre.org/tou/