GHSA-6HH9-W4P2-C5QM
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-63984"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:17Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()\n\nipv6_rpl_srh_decompress() computes:\n\n outhdr-\u003ehdrlen = (((n + 1) * sizeof(struct in6_addr)) \u003e\u003e 3);\n\nhdrlen is __u8. For n \u003e= 127 the result exceeds 255 and silently\ntruncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):\n\n (128 * 16) \u003e\u003e 3 = 256, truncated to 0 as __u8\n\nThe caller in ipv6_rpl_srh_rcv() then places the compressed header\nat buf + ((ohdr-\u003ehdrlen + 1) \u003c\u003c 3). With hdrlen=0 this is buf + 8,\nbut the decompressed region occupies buf[0..2055] (8-byte header\nplus 128 full addresses). The compressed header overlaps the\ndecompressed data, and ipv6_rpl_srh_compress() writes into this\noverlap, corrupting the routing header of the forwarded packet.\n\nThe existing guard at exthdrs.c:546 checks (n + 1) \u003e 255, which\nprevents n+1 from overflowing unsigned char (the segments_left\nfield), but does not prevent the computed hdrlen from overflowing\n__u8. n=127 passes because 128 \u003c= 255, yet hdrlen=256 does not\nfit.\n\nTighten the bound to (n + 1) \u003e 127. This caps n at 126, giving\nhdrlen = (127 * 16) \u003e\u003e 3 = 254, which fits in __u8. The compressed\nheader then lands at buf + ((254 + 1) \u003c\u003c 3) = buf + 2040, exactly\npast the decompressed region (buf[0..2039]). No overlap. 127\nsegments is well beyond any realistic RPL deployment.",
"id": "GHSA-6hh9-w4p2-c5qm",
"modified": "2026-07-20T15:31:54Z",
"published": "2026-07-19T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63984"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3618b34942b76471d044369bfd30d58c39068bf1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fe1cb312038516cb4d9fa089d700af7059f1a64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75b3680047bf09af8e7e471a7a6ddf2ce5847f56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/97e06791368c01f0ad2a4b3269c2abe19485ca32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5e7a46a9f6d8f503b41bfefef70659845f1679"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0487a9c1e116cf349e2d1f302d9019670460858"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de02fc049352af5a9595f015511222d0a85c326b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd238c51b0fa5390cceca9f1ac5a9ffda8063eed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.