CVE-2026-93207

CVE-2026-93207

Critical · published September 24, 2026

CVSS v3.1
9.8
EPSS
0%
Percentile
39.9
In the wild
Unconfirmed
What it is

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

SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry

svcauth_gss_decode_credbody() writes the caller's

rpc_gss_wire_cred field by field and assigns gc_ctx.len only on

the success tail. The caller storage is svcdata->clcred, which

lives in the per-svc_rqst gss_svc_data and is reused across

requests. Early decode failures leave partially decoded state

mixed with residue from the prior request.

The trailing body_len tightness check is the sharpest case:

xdr_stream_decode_opaque_inline() has already written gc_ctx.data

with a borrowed inline pointer into the current request's XDR

pages, but gc_ctx.len retains its prior value. Once the request

pages are released the pooled clcred carries a dangling pointer

paired with a stale length.

Zero the caller's rpc_gss_wire_cred at function entry so that

every early-return path leaves a deterministic all-zero cred.

On the trailing tightness-check path, gc_ctx.len is now zero

instead of stale, which neuters length-driven consumers such as

gss_svc_searchbyctx() that would otherwise walk the dangling

data pointer.

The record
Technical detail
CVSS v3.1
9.8 · CRITICAL
Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0
Not supplied
EPSS
0.00473 · 39.9th percentile
Published
2026-09-24T20:17Z
References (5)
EPSS history
Timeline
  • 26 SEP 03:27Z
    EPSS moved — → 0%
    epss
  • 24 SEP 15:10Z
    SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry
    cvelistv5