Linux: Out-of-bounds Write

What to do

1. Update Linux to c438ba010171b70bad22fc18b1d5bdc3627476e8 or 0452b6526b2f54b2413b9cb4ff1ea2ac542c99c7 or a4437faf135da293d16fcc4cc607316742bd0ebb or 3d5127d998de617b130aae96b138dba22ac6a8a7, whichever matches your release line, or a later version.
2. Update Linux Kernel to 5.10.253 or 5.15.203 or 6.1.168 or 6.6.134, whichever matches your release line, or a later version.
3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

NetworkCan be exploited remotely over a network, including the internet.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

NoneNo account or login is needed.

User interaction

NoneNo action by a victim is required.

Scope

UnchangedImpact stays within the vulnerable component.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Out-of-bounds Write

Timeline

1. May 1, 2026CVE record published.
2. October 16, 2026CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
3. November 11, 2026Record last changed materially (score, affected products, status or references).

References

Recent Out-of-bounds Write vulnerabilities

• 7.5 High severity

  Red Hat Enterprise Linux 10: Out-of-bounds Write

  CVE-2026-37457May 1, 2026Red Hat
• 7.8 High severity

  Linux: Out-of-bounds Write

  CVE-2026-43047May 1, 2026Linux
• 9.8 Critical severity

  Linux: Out-of-bounds Write

  CVE-2026-43037May 1, 2026Linux
• 7.8 High severity

  Linux: Out-of-bounds Write

  CVE-2026-43020May 1, 2026Linux
• 7.8 High severity

  Linux: Out-of-bounds Write

  CVE-2026-31780May 1, 2026Linux
• 7.8 High severity

  Linux: Out-of-bounds Write

  CVE-2026-31772May 1, 2026Linux

Spotted an error? Tell us.