GHSA-6HH9-W4P2-C5QM

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31
VLAI
Details

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.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.


Detection rules are retrieved from Rulezet.