Heimdall Security Logo

CVE-2026-43038

Vulnérabilité critique dans Linux (Linux)

CVSS 9.8 · Critique
EPSS 0.3%
Linux•Linux•Versions : <3d5127d998de617b130aae96b138dba22ac6a8a7, <=6.1.*, <=6.12.*, <0452b6526b2f54b2413b9cb4ff1ea2ac542c99c7, <3.13, ca15a078bd907df5fc1c009477869c5cbde3b753, <c438ba010171b70bad22fc18b1d5bdc3627476e8, 0, 6.6.134, 7.0, <=5.10.*, <=6.6.*, <=6.19.*, <e41953e7d118e2702bcb217879c173d9d1d3cd4e, 5.15.203, <=6.18.*, 3.13, <a4437faf135da293d16fcc4cc607316742bd0ebb, 6.12.81, <1ceeebd5bd6d855b17a5df625109bfe29129d7cf, <86ab3e55673a7a49a841838776f1ab18d23a67b5, <a2edbb6393972a02114b6003953a5cef3104fada, <=*, 5.10.253, <=5.15.*, 6.1.168, 6.18.22, 6.19.12

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.

Gravité et risque d'exploitation

CVE-2026-43038 obtient un score CVSS de 9.8/10, soit une gravité critique. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.26 %, ce qui la place devant 16.1 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <3d5127d998de617b130aae96b138dba22ac6a8a7, <=6.1.*, <=6.12.*, <0452b6526b2f54b2413b9cb4ff1ea2ac542c99c7, <3.13, ca15a078bd907df5fc1c009477869c5cbde3b753, <c438ba010171b70bad22fc18b1d5bdc3627476e8, 0, 6.6.134, 7.0, <=5.10.*, <=6.6.*, <=6.19.*, <e41953e7d118e2702bcb217879c173d9d1d3cd4e, 5.15.203, <=6.18.*, 3.13, <a4437faf135da293d16fcc4cc607316742bd0ebb, 6.12.81, <1ceeebd5bd6d855b17a5df625109bfe29129d7cf, <86ab3e55673a7a49a841838776f1ab18d23a67b5, <a2edbb6393972a02114b6003953a5cef3104fada, <=*, 5.10.253, <=5.15.*, 6.1.168, 6.18.22, 6.19.12) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références

Rechercher une autre CVE