Look up another CVE · open CVE-2026-72317 in the interactive tracker
CVE-2026-72317
SUNRPC: pin upper rpc_clnt across the TLS connect_worker
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72317 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 | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.
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.
include/linux/sunrpc/clnt.h
net/sunrpc/clnt.c
net/sunrpc/xprtsock.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on include/linux/sunrpc/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- sunrpc
Check it on the machine
grep -w CONFIG_SUNRPC /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 sunrpcPrints 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, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_SUNRPC
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-08-15 (2 months 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.64%, higher than 49.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.5 | 6.6.145 | 79cd550f8c88 |
| 6.5 | 6.12.97 | 7a65b41b657b |
| 6.5 | 6.18.40 | 5b0427ba582d |
| 6.5 | 7.1.5 | d49f6d098ed4 |
| 6.5 | 7.2 | 46bc86c83395 |
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
- The flaw is in the SUNRPC TCP-with-TLS client connect_worker processing a remote NFS server's TLS handshake; a malicious or misconfigured server can induce fatal handshake failure over the network before the delayed worker runs, matching network-reachable kTLS/RPC-with-TLS client paths.
- AC:LAttack complexity, low
- An attacker operating a reachable NFS endpoint can reliably cause fatal TLS handshake failure (e.g., reject mTLS client certificates or send TLS alerts) and influence reconnect timing/backoff so client teardown frees rpc_clnt before the queued connect_worker executes.
- PR:NPrivileges required, none
- Exploitation requires no privileges on the victim host; a remote peer only needs the client kernel to initiate or re-establish an NFS RPC-with-TLS connection, and TLS handshake processing occurs before NFS authentication completes.
- UI:NUser interaction, none
- No further victim action is needed once an NFS xprtsec=tls/mtls mount exists because automatic reconnect after server-induced disconnect or handshake failure can trigger the race without additional user interaction.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege boundaries within the same host; this is standard local kernel compromise rather than crossing VM, container, or IOMMU security scopes.
- C:HConfidentiality impact, high
- This is a kernel heap use-after-free where xs_tcp_tls_setup_socket reads multiple fields from a freed rpc_clnt (including cl_cred and cl_program), enabling information disclosure and further exploitation beyond a simple crash.
- I:HIntegrity impact, high
- Use-after-free of rpc_clnt permits corrupting allocator metadata and adjacent kernel objects; freed-object reuse can yield arbitrary write or control-flow hijack primitives, not merely authenticated data alteration.
- A:HAvailability impact, high
- Accessing the freed rpc_clnt produces a refcount_t underflow and kernel oops/panic; even unsuccessful exploitation typically crashes or hangs the system, and repeated reconnect attempts can deny availability.