Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2026-43038 is a critical-severity Type Confusion (CWE-843) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 17th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
This vulnerability is AI-related — categorised as Other Platforms; in the Protocol-Specific Risks risk domain.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — 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-43038 is a vulnerability in the Linux kernel's IPv6 ICMP error handling, specifically within the ip6_err_gen_icmpv6_unreach() function. The issue arises when processing an outer IPv4 ICMP error packet containing a CIPSO IP option; the skb is cloned into skb2 without clearing its cb[] array. This causes IP6CB(skb2) to misinterpret the IPv4 inet_skb_parm as an inet6_skb_parm, where the cipso offset overlaps with dsthao at offset 18. Consequently, icmp6_send() invokes mip6_addr_swap(), which uses ipv6_find_tlv() to scan the inner attacker-controlled IPv6 packet starting at a non-zero offset, potentially identifying a fake TLV without validating the remaining packet length for the full 18-byte struct ipv6_destopt_hao, leading to a possible 16-byte swap extending into skb_shared_info.
Remote attackers with network access can exploit this by sending forged IPv4 ICMP error packets with a crafted CIPSO option, requiring no privileges or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Successful exploitation could enable kernel memory corruption through the out-of-bounds memory operation in mip6_addr_swap(), compromising confidentiality, integrity, and availability with critical severity.
Kernel patches address the vulnerability by clearing skb2->cb[] in ip6_err_gen_icmpv6_unreach(), as implemented in stable commits such as 0452b6526b2f54b2413b9cb4ff1ea2ac542c99c7, 1ceeebd5bd6d855b17a5df625109bfe29129d7cf, 3d5127d998de617b130aae96b138dba22ac6a8a7, 86ab3e55673a7a49a841838776f1ab18d23a67b5, and a2edbb6393972a02114b6003953a5cef3104fada. A separate patch for ip6ip6_err() may be warranted but is not included here.
The flaw was observed by Sashiko AI-review, highlighting AI-assisted kernel auditing. No real-world exploitation is reported.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-26637
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is…
more
cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.
- CWE(s)
AI Security AnalysisAI
- AI Category
- Other Platforms
- Risk Domain
- Protocol-Specific Risks
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: ai
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V3.2.3V15.3.5
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and type-aware analysis) directly finds type-confusion flaws before deployment.
Engineering principles can require use of type-safe languages, static typing, and runtime type checks that structurally avoid allocating one type and accessing another.
Memory-protection controls limit the blast radius when a type-confusion access occurs but do not stop the flaw itself.
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.
Secure SDLC practices directly prevent type-confusion flaws via safe typing, static analysis, and code review while the control itself addresses many additional weaknesses.
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.
Security testing in development can detect type-confusion vulnerabilities through fuzzing and static analysis.
Secure SDLC mandates type-safe design and review that can catch type-confusion flaws.
Application security requirements can specify strong typing and interface contracts that reduce type confusion.
Secure architecture principles promote type-safe languages and memory-safety mechanisms that mitigate type confusion.
Secure coding standards directly forbid unsafe type casts and require static-analysis checks for type confusion.