GHSA-72QV-M5JW-M97F

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-10-30 15:33
VLAI
Details

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

SUNRPC: svcauth_gss: enforce krb5 token minimum length

svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap():

if (len > xdr_stream_remaining(xdr))
        goto unwrap_failed;
offset = xdr_stream_pos(xdr);
...
maj_stat = gss_unwrap(ctx, offset, offset + len, buf);

The wire value len flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s shift %= buf->len path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division.

Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload.

Fix by adding a minimum-length check immediately after the existing upper-bound check:

if (len <= GSS_KRB5_TOK_HDR_LEN)
        goto unwrap_failed;
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-89550"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:38Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: enforce krb5 token minimum length\n\nsvcauth_gss_unwrap_priv() validates only an upper bound on the\nwire-supplied opaque length before handing the buffer to\ngss_unwrap():\n\n    if (len \u003e xdr_stream_remaining(xdr))\n            goto unwrap_failed;\n    offset = xdr_stream_pos(xdr);\n    ...\n    maj_stat = gss_unwrap(ctx, offset, offset + len, buf);\n\nThe wire value `len` flows unchanged as the upper bound into the\nkrb5 unwrap path, so a len in [0, 16] passes this check and is\nhanded to gss_unwrap(). For a krb5 v2 context that lands in\ngss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token\nheader fields at ptr+4 and ptr+6 and then calls rotate_left()\nbefore any integrity check. With a sub-header length the header\nreads run past the token, and _rotate_left()\u0027s `shift %= buf-\u003elen`\npath can divide by zero when buf-\u003elen has been driven to zero by\nthe truncated token. A header-only token (len == 16) is equally\ninvalid: with a non-zero RRC field and the opaque blob ending at\nthe XDR buffer boundary, rotate_left() builds a zero-length\nsubbuffer, reaching the same division.\n\nReject the token at the server entry point before it reaches the\nkrb5 unwrap core. A valid sealed RFC 4121 token must contain\nthe 16-byte header plus at least some encrypted payload.\n\nFix by adding a minimum-length check immediately after the\nexisting upper-bound check:\n\n    if (len \u003c= GSS_KRB5_TOK_HDR_LEN)\n            goto unwrap_failed;",
  "id": "GHSA-72qv-m5jw-m97f",
  "modified": "2026-10-30T15:33:21Z",
  "published": "2026-09-11T21:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89550"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ea5b0c7f212c2772d32c2b88287b89a9cdf6edd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2188232509f1559cb8fcb0c9a4b1e04317fa0f15"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2eed1e6a976a44015c3ee78841fe336796e2b21c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a919c5c88769cf8fb3ec071e6078d830bf512489"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd6afc6cab8c5d387d1ed2f069562ef7bdadd651"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de942dd8c2c8358bcad04ce44271954c48924423"
    }
  ],
  "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.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    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.