{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "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-\u003eiov_base;     if (offset + opaque_len \u003e rcv_buf-\u003elen)             goto unwrap_failed;     maj_stat = gss_unwrap(ctx-\u003egc_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-\u003elen, so the bound check passes and gss_unwrap() is called with end \u003c 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 \u003e rcv_buf-\u003elen)             goto unwrap_failed;     if (opaque_len \u003e rcv_buf-\u003elen - offset)             goto unwrap_failed;     if (opaque_len \u003c 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\").",
  "id": "DEBIAN-CVE-2026-89541",
  "modified": "2026-09-15T08:47:36.920420665Z",
  "published": "2026-09-11T20:19:37.247Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89541"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-89541"
  ]
}