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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - A remote NFS/SUNRPC peer sends an RPC Call with flavor RPC_AUTH_GSS whose rpc_gss_cred_t fails the body_len tightness check in svcauth_gss_decode_credbody(); those cred bytes arrive on nfsd TCP/UDP 2049 via svc_recv → svc_tcp_recvfrom/svc_udp_recvfrom → svc_process → svc_process_common → svc_authenticate → svcauth_gss_accept.
AC:L - The attacker first sends a well-formed RPCSEC_GSS cred so decode assigns gc_ctx.len, then a second Call where xdr_stream_decode_opaque_inline() succeeds but body_len != XDR_UNIT*5+xdr_align_size(handle_len). Both hit the same nfsd thread's reused gss_svc_data.clcred; the tightness failure is deterministic with no race.
PR:N - svcauth_gss_decode_credbody() is the RPC_AUTH_GSS credential decoder inside svcauth_gss_accept(), reached before gss_svc_searchbyctx(), gss_verify_mic(), or nfsd export/client checks. Flavor 6 with auth_rpcgss registered (RPCSEC_GSS_KRB5 defaults y) needs no Kerberos ticket, uid, or capability.
UI:N - nfsd processes each inbound RPC in the service thread via svc_process with no local user or administrator action; the attacker alone sends the residue-planting Call and the tightness-fail Call.
S:U - The dangling gc_ctx pointer, consume_skb() of the UDP receive skb, and any later kmemdup of that pointer occur in the host nfsd/SUNRPC kernel. No VM, IOMMU, or sandbox boundary is crossed.
C:H - On tightness failure, xdr_stream_decode_opaque_inline() writes gc_ctx.data into the UDP in-place skb (svc_udp_recvfrom) while gc_ctx.len stays the prior handle length. svc_udp_release_ctxt() consume_skb() then frees that skb; gss_svc_searchbyctx()→dup_to_netobj() kmemdups handle->len bytes from the dangling pointer, a UAF read of reclaimed kernel memory.
I:H - The leftover clcred.gc_ctx is a use-after-free of skb-backed memory with an attacker-chosen stale length planted by the prior GSS handle. Spraying the consumed skb lets length-driven consumers of that netobj treat attacker bytes as kernel objects, so integrity impact is High as for other kernel UAFs.
A:H - Walking gc_ctx.data after consume_skb() oopses the nfsd thread when the skb is reused or unmapped, and the attacker can repeat tightness-fail Calls to kill service threads or panic the host where panic_on_oops is set.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - A remote NFS/SUNRPC peer sends an RPC Call with flavor RPC_AUTH_GSS whose rpc_gss_cred_t fails the body_len tightness check in svcauth_gss_decode_credbody(); those cred bytes arrive on nfsd TCP/UDP 2049 via svc_recv → svc_tcp_recvfrom/svc_udp_recvfrom → svc_process → svc_process_common → svc_authenticate → svcauth_gss_accept.
AC:L - The attacker first sends a well-formed RPCSEC_GSS cred so decode assigns gc_ctx.len, then a second Call where xdr_stream_decode_opaque_inline() succeeds but body_len != XDR_UNIT*5+xdr_align_size(handle_len). Both hit the same nfsd thread's reused gss_svc_data.clcred; the tightness failure is deterministic with no race.
PR:N - svcauth_gss_decode_credbody() is the RPC_AUTH_GSS credential decoder inside svcauth_gss_accept(), reached before gss_svc_searchbyctx(), gss_verify_mic(), or nfsd export/client checks. Flavor 6 with auth_rpcgss registered (RPCSEC_GSS_KRB5 defaults y) needs no Kerberos ticket, uid, or capability.
UI:N - nfsd processes each inbound RPC in the service thread via svc_process with no local user or administrator action; the attacker alone sends the residue-planting Call and the tightness-fail Call.
S:U - The dangling gc_ctx pointer, consume_skb() of the UDP receive skb, and any later kmemdup of that pointer occur in the host nfsd/SUNRPC kernel. No VM, IOMMU, or sandbox boundary is crossed.
C:H - On tightness failure, xdr_stream_decode_opaque_inline() writes gc_ctx.data into the UDP in-place skb (svc_udp_recvfrom) while gc_ctx.len stays the prior handle length. svc_udp_release_ctxt() consume_skb() then frees that skb; gss_svc_searchbyctx()→dup_to_netobj() kmemdups handle->len bytes from the dangling pointer, a UAF read of reclaimed kernel memory.
I:H - The leftover clcred.gc_ctx is a use-after-free of skb-backed memory with an attacker-chosen stale length planted by the prior GSS handle. Spraying the consumed skb lets length-driven consumers of that netobj treat attacker bytes as kernel objects, so integrity impact is High as for other kernel UAFs.
A:H - Walking gc_ctx.data after consume_skb() oopses the nfsd thread when the skb is reused or unmapped, and the attacker can repeat tightness-fail Calls to kill service threads or panic the host where panic_on_oops is set.
CVSS 3.1