Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-43037 is a critical-severity Out-of-bounds Write (CWE-787) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Junk Data (T1001.001); ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-43037 is a vulnerability in the Linux kernel's ip6_tunnel module, specifically within the ip4ip6_err() function. The issue arises when ip4ip6_err() calls icmp_send() on a cloned socket buffer (skb) whose control block (cb[]) has been populated by the IPv6 receive path as a struct inet6_skb_parm. The icmp_send() function then passes IPCB(skb2) to __ip_options_echo(), which misinterprets the cb[] region as a struct inet_skb_parm for IPv4 processing. Due to differing layouts—particularly inet6_skb_parm.nhoff at offset 14 overlapping inet_skb_parm.opt.rr—this results in a non-zero record route (rr) value, causing __ip_options_echo() to read an optlen from attacker-controlled packet data at sptr[rr+1] and copy that many bytes into a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE), leading to a stack-based buffer overflow.
A remote, unauthenticated attacker can exploit this vulnerability by sending crafted IPv6 packets that trigger the ip4ip6_err() path in IP-in-IP6 tunneling scenarios. The CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects its high severity, with network accessibility, low attack complexity, and no privileges required. Successful exploitation enables high-impact confidentiality, integrity, and availability violations, potentially allowing arbitrary code execution, data corruption, or system crashes via the stack buffer overflow.
Kernel patches addressing this vulnerability, available in stable repositories, clear the skb2->cb[] area before processing and add minimal IPv4 header validation to ensure version 4 and IHL >= 5. Relevant commits include 1063515ce15ff31065c4e7f8265f4c2fd3c54876, 2cc6e3b0fe0f0242d1f530a93a4924f48ab85ba5, 2edfa31769a4add828a7e604b21cb82aaaa05925, 4a622658f384b03560834cbe8ffcfe69a278f7c8, and 590f622669b97eaf7b57a1de7b0a6e68c5d8b2c3. Security practitioners should update to kernels incorporating these fixes to mitigate exposure in environments using IP6 tunneling.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-26636
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm.…
more
icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V15.3.5
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and bounds checks) finds out-of-bounds write flaws before deployment.
Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.
Engineering principles can require use of type-safe languages, static typing, and runtime type checks that structurally avoid allocating one type and accessing another.
Input validation can structurally reject or sanitize data that would otherwise trigger an out-of-bounds write.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Secure-development practices (static analysis, bounds checking, code review) are the primary means of preventing out-of-bounds writes.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.