critical

CVE

CVE-2026-93207

CWE

Not mapped

Affected Surface

  • Linux kernel SUNRPC server-side GSS credential decoder in svcauth_gss_decode_credbody()
  • Linux kernel versions 6.3.0 through 6.6.156, 6.7.0 through 6.12.108, 6.13.0 through 6.18.49, and 6.19.0 through 7.2.3
  • NFS and other SUNRPC services that accept RPCSEC_GSS or Kerberos-authenticated requests
  • Linux distributions carrying the vulnerable SUNRPC code until their vendor kernel backport lands

CVE-2026-93207 was published on 2026-09-24 and scored 9.8. The bug is in the Linux kernel’s SUNRPC server-side GSS credential decoder, “svcauth_gss_decode_credbody()”. A malformed RPCSEC_GSS credential body can leave reused request state with a pointer into request-owned XDR pages and a stale length copied forward from an older request. Later code treats that pair as a valid GSS context handle.

That matters when a Linux host exposes RPC services that accept Kerberos or RPCSEC_GSS authentication. NFS servers are the obvious case, but they are not the only one. The vulnerable path is in the shared SUNRPC stack, so the right question is not “do I run Linux?” It is “do I expose a SUNRPC service that parses GSS credentials from the network?”

Affected packages and projects

The affected project is the Linux kernel, specifically the server-side SUNRPC authentication path:

ComponentWhy it matters
net/sunrpc/auth_gss/svcauth_gss.cContains “svcauth_gss_decode_credbody()” and the reused “svcdata->clcred” state
rpc_gss_wire_credHolds the decoded RPCSEC_GSS credential, including “gc_ctx.data” and “gc_ctx.len”
gss_svc_searchbyctx()Copies “handle->data” and “handle->len” into a cache lookup, which is where the stale pointer-length pair becomes dangerous
NFS or other SUNRPC services with GSS enabledProvide the remotely reachable parsing surface

Version tracking from the public CVE data and fix metadata lines up as follows:

BranchVulnerable rangeFixed in
Linux 6.6 LTS line6.3.0 through 6.6.1566.6.157
Linux 6.12 LTS line6.7.0 through 6.12.1086.12.109
Linux 6.18 line6.13.0 through 6.18.496.18.50
Linux mainline progression6.19.0 through 7.2.37.2.4

Distribution kernels may backport the fix under a different release number. On vendor kernels, trust the distro advisory more than the upstream version string.

Root cause

The vulnerable function decodes an incoming RPCSEC_GSS credential directly into a “rpc_gss_wire_cred” object that lives inside “svcdata->clcred”. That storage is reused across requests. Before the fix, the decoder wrote fields one by one and only assigned “gc_ctx.len” on the success path:

if (xdr_stream_decode_u32(xdr, &gc->gc_v) < 0)
	return false;
if (xdr_stream_decode_u32(xdr, &gc->gc_proc) < 0)
	return false;
if (xdr_stream_decode_u32(xdr, &gc->gc_seq) < 0)
	return false;
if (xdr_stream_decode_u32(xdr, &gc->gc_svc) < 0)
	return false;
handle_len = xdr_stream_decode_opaque_inline(xdr,
					     (void **)&gc->gc_ctx.data,
					     body_len);
if (handle_len < 0)
	return false;
if (body_len != XDR_UNIT * 5 + xdr_align_size(handle_len))
	return false;

gc->gc_ctx.len = handle_len;
return true;

The dangerous case is the last length check. By that point, “xdr_stream_decode_opaque_inline()” has already written “gc->gc_ctx.data” with a borrowed pointer into the current request’s XDR buffer. If the function returns false before “gc->gc_ctx.len = handle_len”, the old length from the previous request can survive in the reused object.

That leaves the kernel with a mixed state:

current request: gc_ctx.data -> borrowed pointer into this request's XDR pages
previous request: gc_ctx.len -> stale non-zero length
reused object: svcdata->clcred

Once the current request pages are released, “gc_ctx.data” is no longer valid. Later consumers still see a non-zero length and may treat the pair as a real context handle.

Why the stale pointer can still be reached

The next step after decoding is a context lookup:

rsci = gss_svc_searchbyctx(sn->rsc_cache, &gc->gc_ctx);
if (!rsci)
	goto auth_err;

Inside “gss_svc_searchbyctx()”, the kernel duplicates the handle using the provided pointer and length:

static struct rsc *gss_svc_searchbyctx(struct cache_detail *cd,
				       struct xdr_netobj *handle)
{
	struct rsc rsci;

	memset(&rsci, 0, sizeof(rsci));
	if (dup_to_netobj(&rsci.handle, handle->data, handle->len))
		return NULL;
	...
}

That is the boundary that makes the bug more than a parse failure. The caller is no longer just rejecting a bad packet. It is copying from a pointer-length pair that may describe freed request memory.

What changed in the fix

The upstream fix is short:

/* Early-return paths leave deterministic state, not stale residue. */
memset(gc, 0, sizeof(*gc));

That line now runs at the start of “svcauth_gss_decode_credbody()”. If any decode step fails, the reused object stays zeroed instead of carrying forward length and pointer residue from different requests.

This is not a large parser rewrite. It is a state-reset fix. That is also why the issue is easy to miss in review. The field decodes look ordinary, but the object lifetime is longer than one packet.

Exposure checklist

Not every Linux host is equally exposed. Prioritize systems that satisfy both conditions:

  1. They expose SUNRPC services to untrusted networks or tenants.
  2. They use RPCSEC_GSS or Kerberos-authenticated RPC flows.

Good first checks:

uname -r
rpcinfo -p localhost 2>/dev/null
grep -RniE 'sec=krb5|sec=krb5i|sec=krb5p' /etc/exports /etc/exports.d 2>/dev/null

If you run NFS with Kerberos, inspect the server path first. Plain AUTH_SYS exports still matter operationally, but the published root cause here is tied to the GSS credential decoder.

Remediation

Patch to a fixed vendor kernel or to the nearest upstream fixed release in your branch: 6.6.157, 6.12.109, 6.18.50, or 7.2.4. Because the issue is in kernel request parsing, service restarts without a kernel update do not remove the vulnerable code path.

While you wait for a vendor update, reduce reachable surface:

  • Restrict network access to NFS and other SUNRPC services.
  • Disable Kerberos-authenticated RPC exposure where it is not required.
  • Move externally reachable RPC services behind trusted network boundaries and VPN controls.
  • Audit internet-exposed file services and shared storage nodes first.

After patching, reboot into the fixed kernel and confirm the running version instead of only checking installed packages:

uname -r

Detection and response

There is no public exploit in the sources reviewed for this article, and the public reporting is stronger on root cause than on exploitation telemetry. Treat the issue as a remote kernel attack surface reduction problem:

  • Review recent crashes or authentication anomalies in NFS or SUNRPC services that use GSS.
  • Check whether any exposed RPC services accepted Kerberos-authenticated traffic from untrusted networks.
  • Preserve kernel logs and packet captures if you suspect malformed RPCSEC_GSS traffic reached an exposed service.

If you cannot quickly prove that a server never exposed this path, patch first and then narrow the blast radius review to hosts that both served SUNRPC and used GSS authentication.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Use AI-native static analysis to find similar application vulnerabilities and generate review-ready fixes.

Explore AI SAST Explore secrets scanning Get Demo

References