CVE-2026-63984

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

ipv6: rpl: fix hdrlen overflow in ipv6rplsrh_decompress()

ipv6rplsrh_decompress() computes:

    outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);

hdrlen is __u8. For n >= 127 the result exceeds 255 and silently

truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):

    (128 * 16) >> 3 = 256, truncated to 0 as __u8

The caller in ipv6rplsrh_rcv() then places the compressed header

at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8,

but the decompressed region occupies buf[0..2055] (8-byte header

plus 128 full addresses). The compressed header overlaps the

decompressed data, and ipv6rplsrh_compress() writes into this

overlap, corrupting the routing header of the forwarded packet.

The existing guard at exthdrs.c:546 checks (n + 1) > 255, which

prevents n+1 from overflowing unsigned char (the segments_left

field), but does not prevent the computed hdrlen from overflowing

__u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not

fit.

Tighten the bound to (n + 1) > 127. This caps n at 126, giving

hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed

header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly

past the decompressed region (buf[0..2039]). No overlap. 127

segments is well beyond any realistic RPL deployment.