Linux · Kernel · Linux Kernel Out-of-Bounds Write Vulnerability
Verdict
Patch on your normal cycle · actively exploited, not reachable unauthenticated from the internet, and in the upper half of CVEs by near-term exploitation probability
Added to CISA KEV 2026-09-18 · exploited in the wild for 9 days
CVSS 8.8 HIGH. The score is a summary; these three components are the part that decides whether something scanning the internet can use it.
| Attack vector | localrequires local access to the machine |
|---|---|
| Privileges required | lowneeds some credentials, so a fully anonymous attacker cannot reach it directly |
| User interaction | nonecan be triggered with nobody interacting with the page or request |
| Base vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
| Weakness | CWE-787 |
This describes the vulnerability. It says nothing about whether your systems run it.
EPSS puts the probability of exploitation in the next 30 days at 0.0065, which places it in the upper half of all tracked CVEs. The percentile is the more useful half: 0.18 in absolute terms sounds low until you know most of the internet-facing software in the world scores under that.
| EPSS probability | 0.0065 |
|---|---|
| Percentile | 0.489 — upper half |
| Added to KEV | 2026-09-18 |
|---|---|
| Days exploited | 9 |
| Federal remediation due | not set |
| Ransomware use | no known ransomware campaign use |
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.
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().