CVE-2026-63984: In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompr...

Description

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_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 ipv6_rpl_srh_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 ipv6_rpl_srh_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.

Metrics

CVSS 3.1

9.8/10

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS Probability

0.51%

40.9th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < 75b3680047bf09af8e7e471a7a6ddf2ce5847f56; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < fd238c51b0fa5390cceca9f1ac5a9ffda8063eed; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < 3618b34942b76471d044369bfd30d58c39068bf1; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < 97e06791368c01f0ad2a4b3269c2abe19485ca32; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < de02fc049352af5a9595f015511222d0a85c326b; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < 6fe1cb312038516cb4d9fa089d700af7059f1a64; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < c0487a9c1e116cf349e2d1f302d9019670460858; >= 8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3, < 9d5e7a46a9f6d8f503b41bfefef70659845f1679
Linux	Linux	5.7

References

Timeline

Published: Jul 19, 2026
Last Modified: Jul 30, 2026
Status: Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-63984?

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_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 ipv6_rpl_srh_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 ipv6_rpl_srh_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.

How severe is CVE-2026-63984?

CVE-2026-63984 has a CVSS score of 9.8/10 (CRITICAL severity). The EPSS model estimates a 0.51% probability of exploitation in the next 30 days.

How do I fix CVE-2026-63984?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →