CVE-2026-43501

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: rpl: reserve mac_len headroom when recompressed SRH grows<br /> <br /> ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps<br /> the next segment into ipv6_hdr-&gt;daddr, recompresses, then pulls the old<br /> header and pushes the new one plus the IPv6 header back. The<br /> recompressed header can be larger than the received one when the swap<br /> reduces the common-prefix length the segments share with daddr (CmprI=0,<br /> CmprE&gt;0, seg[0][0] != daddr[0] gives the maximum +8 bytes).<br /> <br /> pskb_expand_head() was gated on segments_left == 0, so on earlier<br /> segments the push consumed unchecked headroom. Once skb_push() leaves<br /> fewer than skb-&gt;mac_len bytes in front of data,<br /> skb_mac_header_rebuild()&amp;#39;s call to:<br /> <br /> skb_set_mac_header(skb, -skb-&gt;mac_len);<br /> <br /> will store (data - head) - mac_len into the u16 mac_header field, which<br /> wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB<br /> past skb-&gt;head.<br /> <br /> A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two<br /> segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one<br /> pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.<br /> <br /> Fix this by expanding the head whenever the remaining room is less than<br /> the push size plus mac_len, and request that much extra so the rebuilt<br /> MAC header fits afterwards.