Linux kernel SUNRPC server GSS auth (svcauth_gss_decode_credbody): svcauth_gss_decode_credbody() fills the caller's

CVSS 9.8CVE-2026-93207Kernel, userspace & hypervisorcurated

Impact

svcauth_gss_decode_credbody() fills the caller's rpc_gss_wire_cred field by field and only sets gc_ctx.len on the success path. The storage is svcdata->clcred in the per-svc_rqst gss_svc_data, which is reused across requests, so an early decode failure leaves fresh partial state mixed with residue from the previous request. On the trailing body_len check in particular, gc_ctx.data already holds a borrowed inline pointer into the current request's XDR pages while gc_ctx.len still holds the old value; once those pages are released the pooled cred carries a dangling pointer with a stale length, which length-driven consumers such as gss_svc_searchbyctx() will walk. This affects nodes acting as a kernel NFS server with Kerberos (sec=krb5*) - shared dataset and home-directory servers in a GPU cluster - and is reachable by any client that can send a malformed RPCSEC_GSS credential.

Who can reach it

Any host that can reach the kernel NFS server's RPC port and send a malformed RPCSEC_GSS cred body. No valid Kerberos credential is needed, since the fault is on the decode-failure path. Only affects servers exporting with krb5 security.

What to do

Take the stable-kernel fix on NFS server nodes (five stable branches carry it) and reboot. There is no runtime toggle short of dropping krb5 security from exports, which is not a realistic mitigation for most sites. NFS clients are not affected.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-93207 https://git.kernel.org/stable/c/0e18641708eaa8bc3c1ff338cd844aeadbd52bac https://git.kernel.org/stable/c/e0778464049b0238f2915a40007a4154f86cf351

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.