GHSA-8539-CX26-HF58

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: validate extension header length before copying to cmsg

ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read:

BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620

Add ipv6_get_exthdr_len() which validates that at least two bytes are accessible before reading the hdrlen field, then checks the computed length against skb_tail_pointer(skb), returning 0 on failure. Extension headers are kept in the linear skb area by pskb_may_pull() during input, so skb_tail_pointer() is the correct bound.

Use ipv6_get_exthdr_len() at all non-AH call sites: the five standalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR) and the three standard cases in the extension-header walk loop (DSTOPTS, ROUTING, default). AH retains an inline bounds check because its length formula differs ((ptr[1]+2)<<2).

The walk loop also gets a pre-read bounds check at the top to validate ptr before any case accesses ptr[0] or ptr[1].

When the walk loop detects a corrupted header, return from the function instead of continuing to process later socket options.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63920"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: validate extension header length before copying to cmsg\n\nip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}\ncmsgs (and their IPV6_2292* legacy counterparts) by trusting the\non-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.\nThe length was validated only at parse time (ipv6_parse_hopopts(),\netc.).  An nftables payload-write expression can rewrite hdrlen after\nparsing and before the skb reaches recvmsg; the write itself is\nin-bounds but put_cmsg() then reads up to ((hdrlen+1) \u003c\u003c 3) = 2040\nbytes from an 8-byte header.  nftables is reachable from an\nunprivileged user namespace, so this is an unprivileged\nslab-out-of-bounds read:\n\n  BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540\n   put_cmsg+0x3ac/0x540\n   udpv6_recvmsg+0xca0/0x1250\n   sock_recvmsg+0xdf/0x190\n   ____sys_recvmsg+0x1b1/0x620\n\nAdd ipv6_get_exthdr_len() which validates that at least two bytes\nare accessible before reading the hdrlen field, then checks the\ncomputed length against skb_tail_pointer(skb), returning 0 on\nfailure.  Extension headers are kept in the linear skb area by\npskb_may_pull() during input, so skb_tail_pointer() is the correct\nbound.\n\nUse ipv6_get_exthdr_len() at all non-AH call sites: the five\nstandalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR)\nand the three standard cases in the extension-header walk loop\n(DSTOPTS, ROUTING, default).  AH retains an inline bounds check\nbecause its length formula differs ((ptr[1]+2)\u003c\u003c2).\n\nThe walk loop also gets a pre-read bounds check at the top to\nvalidate ptr before any case accesses ptr[0] or ptr[1].\n\nWhen the walk loop detects a corrupted header, return from the\nfunction instead of continuing to process later socket options.",
  "id": "GHSA-8539-cx26-hf58",
  "modified": "2026-07-20T15:31:51Z",
  "published": "2026-07-19T18:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63920"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/08464413e628803bd10cb1df68d0138665f2f885"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d330eff318c0f44d4fb0ad2c2aef38f87f24c90"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/81394827dfb72772c50d0ae3bdfa094428a5d76d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/931b4a1f13408c2507719890f78f7227c34a0282"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a29768d56eb3798c052ad3281b05596e695a17af"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a35daeabb433686234b010ebf7b53778dbd6c9b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd433671fef381fdaf7b530c631e6b782d66e224"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb18a1b1644e4cad978df2131e2bb9a2e6886992"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

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.


Loading…