CVE-2026-43038
Essential information
- Published
- 01/05/2026 15:16
- Modified
- 01/05/2026 15:24
- Author
- —
- Creator
- —
- CISA KEV
- No
- CWE
- —
- CVSS vector
- — — —
Description
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 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.
NVD status
- Status
- Awaiting Analysis — CVE has been marked for Analysis. Normally once in this state the CVE will be analyzed by NVD staff within 24 hours.
- Source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- NVD
- View on NVD
Affected products (CPE)
| Product | CPE |
|---|---|
| linux / linux kernel | cpe:2.3:a:linux:linux_kernel:*:*:*:*:*:*:*:* |