CVE-2026-63984: Linux kernel · ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 9.8 Critical · fixed in fd238c51b0fa5390cceca9f1ac5a9ffda8063eed : patch Linux kernel as a priority.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 43% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers can reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in fd238c51b0fa5390cceca9f1ac5a9ffda8063eed, de02fc049352af5a9595f015511222d0a85c326b, c0487a9c1e116cf349e2d1f302d9019670460858 +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
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.
References
- git.kernel.org/stable/c/75b3680047bf09af8e7e471a7a6ddf2ce5847f56 (opens in a new tab)
- git.kernel.org/stable/c/fd238c51b0fa5390cceca9f1ac5a9ffda8063eed (opens in a new tab)
- git.kernel.org/stable/c/3618b34942b76471d044369bfd30d58c39068bf1 (opens in a new tab)
- git.kernel.org/stable/c/97e06791368c01f0ad2a4b3269c2abe19485ca32 (opens in a new tab)
- git.kernel.org/stable/c/de02fc049352af5a9595f015511222d0a85c326b (opens in a new tab)
- git.kernel.org/stable/c/6fe1cb312038516cb4d9fa089d700af7059f1a64 (opens in a new tab)
- git.kernel.org/stable/c/c0487a9c1e116cf349e2d1f302d9019670460858 (opens in a new tab)
- git.kernel.org/stable/c/9d5e7a46a9f6d8f503b41bfefef70659845f1679 (opens in a new tab)