CVE-2026-93207: SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Zero rpcgsswirecred at svcauthgssdecodecredbody() entry
svcauthgssdecodecredbody() writes the caller's rpcgsswirecred field by field and assigns gcctx.len only on the success tail. The caller storage is svcdata->clcred, which lives in the per-svcrqst gsssvcdata and is reused across requests. Early decode failures leave partially decoded state mixed with residue from the prior request.
The trailing bodylen tightness check is the sharpest case: xdrstreamdecodeopaqueinline() has already written gcctx.data with a borrowed inline pointer into the current request's XDR pages, but gcctx.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 rpcgsswirecred at function entry so that every early-return path leaves a deterministic all-zero cred. On the trailing tightness-check path, gcctx.len is now zero instead of stale, which neuters length-driven consumers such as gsssvcsearchbyctx() that would otherwise walk the dangling data pointer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In svcauth_gss_decode_credbody(), zero the caller's rpc_gss_wire_cred at function entry before decoding, so every early-return path leaves an all-zero credential and does not retain a stale gc_ctx.data pointer or gc_ctx.len.
Event History
Frequently Asked Questions
What does an attacker need to send to reach the dangerous state?
The request must cause credential decoding to fail after an inline context pointer has been stored but before the context length is assigned. The described sharpest case is a trailing body-length tightness check failure in the XDR credential body.
What can happen after a failed credential decode?
Before the fix, pooled credential storage could retain a pointer into released request XDR pages together with a stale length from an earlier request. Length-driven consumers, including gss_svc_searchbyctx(), could then walk the dangling data pointer.
Does every credential decoding failure create the same condition?
Early decode failures can leave partially decoded fields mixed with residue from a prior request because the credential storage is reused across requests. The trailing body-length check is specifically identified as the case that can leave a borrowed current-request pointer paired with a prior length.