Look up another CVE · open CVE-2026-93207 in the interactive tracker
CVE-2026-93207
SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry
Published 2026-09-24 (24 days ago) by the Linux kernel CNA. Subsystem net/sunrpc. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-93207 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/sunrpc/auth_gss/svcauth_gss.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on net/sunrpc/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- auth_rpcgss
Check it on the machine
grep -wE 'CONFIG_SUNRPC|CONFIG_SUNRPC_GSS' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w auth_rpcgssPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_SUNRPC, CONFIG_SUNRPC_GSS
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-24 (24 days ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.47%, higher than 39.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/sunrpc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.3 | 6.6.157 | 56b29d62017c |
| 6.3 | 6.12.109 | 0e18641708ea |
| 6.3 | 6.18.50 | e0778464049b |
| 6.3 | 7.2.4 | 0fa8a8acae57 |
| 6.3 | 7.3 | 11539e8fcce0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- 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:LAttack complexity, low
- 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:NPrivileges required, none
- 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:NUser interaction, none
- 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:UScope, unchanged
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.