GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-8H82-J8R3-JR82

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: harden gss_unwrap_resp_priv length checks

gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with

offset = (u8 *)(p) - (u8 *)head->iov_base;
if (offset + opaque_len > rcv_buf->len)
        goto unwrap_failed;
maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset,
                      offset + opaque_len, rcv_buf);

Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token.

A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows.

Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length:

if (offset > rcv_buf->len)
        goto unwrap_failed;
if (opaque_len > rcv_buf->len - offset)
        goto unwrap_failed;
if (opaque_len < GSS_KRB5_TOK_HDR_LEN)
        goto unwrap_failed;

The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").

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-89541"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:37Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: harden gss_unwrap_resp_priv length checks\n\ngss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with\n\n    offset = (u8 *)(p) - (u8 *)head-\u003eiov_base;\n    if (offset + opaque_len \u003e rcv_buf-\u003elen)\n            goto unwrap_failed;\n    maj_stat = gss_unwrap(ctx-\u003egc_gss_ctx, offset,\n                          offset + opaque_len, rcv_buf);\n\nBoth operands are u32 and the sum is computed in u32. A reply with\nopaque_len near 0xffffffff makes offset + opaque_len wrap to a small\nvalue that is below rcv_buf-\u003elen, so the bound check passes and\ngss_unwrap() is called with end \u003c begin. The check also lacks a\nlower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is\naccepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt\nheader reads at ptr+4 and ptr+6 then run past the token.\n\nA krb5p NFS server returning a crafted RPCSEC_GSS reply can drive\nthe client into out-of-bounds reads in gss_krb5_unwrap_v2() and the\nrotate_left() loop that follows.\n\nFix by replacing the single combined check with three guards that\nare safe in u32 arithmetic and that enforce the RFC 4121 minimum\nouter token length:\n\n    if (offset \u003e rcv_buf-\u003elen)\n            goto unwrap_failed;\n    if (opaque_len \u003e rcv_buf-\u003elen - offset)\n            goto unwrap_failed;\n    if (opaque_len \u003c GSS_KRB5_TOK_HDR_LEN)\n            goto unwrap_failed;\n\nThe first guard makes the subtraction in the second guard\nunconditionally safe; offset is derived from a successful\nxdr_inline_decode() in the head kvec, so in practice it already\nsatisfies the bound. The floor mirrors the server-side check added\nin commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token\nminimum length\").",
  "id": "GHSA-8h82-j8r3-jr82",
  "modified": "2026-09-14T15:32:28Z",
  "published": "2026-09-11T21:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89541"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3691c4b3488d8ca046b9941e5be30c626dbbbb50"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/401f6a5b338d05bb1069ad814d9f77e3c367854f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/81fd7654a8429718adfcb2a7e03496077f547ed0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/85fa6b12e8f439739ac36ef2aad925f37c8b976a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87831b92112c81db251d46756d65daa4f91af6a2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/89a15a50f84d32d4b99db86f957427fcbe20a99a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d395c30d570ca6168f0297b191709927d1258273"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ebcbd2523a8524c3d24e111cdbed8e271d910269"
    }
  ],
  "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.