Answer in brief
CVE-2026-63984 records a Unknown severity vulnerability in ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-63984 records a Unknown severity vulnerability in ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <75b3680047bf09af8e7e471a7a6ddf2ce5847f56 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <fd238c51b0fa5390cceca9f1ac5a9ffda8063eed || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <3618b34942b76471d044369bfd30d58c39068bf1 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <97e06791368c01f0ad2a4b3269c2abe19485ca32 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <de02fc049352af5a9595f015511222d0a85c326b || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <6fe1cb312038516cb4d9fa089d700af7059f1a64 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <c0487a9c1e116cf349e2d1f302d9019670460858 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <9d5e7a46a9f6d8f503b41bfefef70659845f1679 | 75b3680047bf09af8e7e471a7a6ddf2ce5847f56, fd238c51b0fa5390cceca9f1ac5a9ffda8063eed, 3618b34942b76471d044369bfd30d58c39068bf1, 97e06791368c01f0ad2a4b3269c2abe19485ca32, de02fc049352af5a9595f015511222d0a85c326b, 6fe1cb312038516cb4d9fa089d700af7059f1a64, c0487a9c1e116cf349e2d1f302d9019670460858, 9d5e7a46a9f6d8f503b41bfefef70659845f1679 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <75b3680047bf09af8e7e471a7a6ddf2ce5847f56 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <fd238c51b0fa5390cceca9f1ac5a9ffda8063eed || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <3618b34942b76471d044369bfd30d58c39068bf1 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <97e06791368c01f0ad2a4b3269c2abe19485ca32 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <de02fc049352af5a9595f015511222d0a85c326b || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <6fe1cb312038516cb4d9fa089d700af7059f1a64 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <c0487a9c1e116cf349e2d1f302d9019670460858 || >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <9d5e7a46a9f6d8f503b41bfefef70659845f1679 | 75b3680047bf09af8e7e471a7a6ddf2ce5847f56, fd238c51b0fa5390cceca9f1ac5a9ffda8063eed, 3618b34942b76471d044369bfd30d58c39068bf1, 97e06791368c01f0ad2a4b3269c2abe19485ca32, de02fc049352af5a9595f015511222d0a85c326b, 6fe1cb312038516cb4d9fa089d700af7059f1a64, c0487a9c1e116cf349e2d1f302d9019670460858, 9d5e7a46a9f6d8f503b41bfefef70659845f1679 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.