CVE-2026-43501

In the Linux kernel, the following vulnerability has been resolved:

ipv6: rpl: reserve mac_len headroom when recompressed SRH grows

ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps

the next segment into ipv6_hdr->daddr, recompresses, then pulls the old

header and pushes the new one plus the IPv6 header back. The

recompressed header can be larger than the received one when the swap

reduces the common-prefix length the segments share with daddr (CmprI=0,

CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskb_expand_head() was gated on segments_left == 0, so on earlier

segments the push consumed unchecked headroom. Once skb_push() leaves

fewer than skb->mac_len bytes in front of data,

skb_mac_header_rebuild()'s call to:

skb_set_mac_header(skb, -skb->mac_len);

will store (data - head) - mac_len into the u16 mac_header field, which

wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB

past skb->head.

A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two

segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one

pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.

Fix this by expanding the head whenever the remaining room is less than

the push size plus mac_len, and request that much extra so the rebuilt

MAC header fits afterwards.