CRITICAL Introduced in 6.3
sunrpc WireCred UAF
CVE-2026-93207
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
KernelScan AI9.8CRITICAL
01Description
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.
02KernelScan AI Analysis
Risk summary
A network client can trigger a use-after-free in the kernel's RPCSEC_GSS server-side credential decoder by sending a sequence of crafted RPC requests. The dangling pointer and stale length left in a pooled credential structure can be walked on a subsequent request, reading or corrupting freed memory. Any system acting as an NFS or RPC server with Kerberos/GSS authentication is at risk.
Vulnerability analysis
When the kernel's RPCSEC_GSS server decodes an incoming credential, it writes fields one at a time into a per-thread credential structure that is reused across requests, but only sets the context length on the success path. If decoding fails partway through — for example on a trailing length-consistency check — a borrowed pointer into the current request's data pages is left in the structure while the length retains its value from a previous request. Once those request pages are freed, the pooled credential carries a dangling pointer paired with a stale non-zero length, and a subsequent request on the same server thread can cause internal lookup routines to follow that pointer into freed memory. The fix zeroes the entire credential structure at the start of the decode function, so every early-return path leaves a clean all-zero credential with a zero length that prevents consumers from dereferencing the dangling pointer. This is reachable by any network client that can send RPC requests to a server using RPCSEC_GSS authentication such as NFS with Kerberos; no prior authentication or local access is required.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 6.3 | 6.12.109 | 0e18641708ea |
| 7.2 | 6.3 | 7.2.4 | 0fa8a8acae57 |
| mainline | 6.3 | 7.3-rc1 | 11539e8fcce0 |
| 6.6 | 6.3 | 6.6.157 | 56b29d62017c |
| 6.18 | 6.3 | 6.18.50 | e0778464049b |