CVE-2026-72317

What it is

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker 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.

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of data exposure, data tampering, service disruption.

Exploit odds

0.6% chance of exploitation in the next 30 days (EPSS).

Fix

No patch or advisory is linked yet. Look at mitigations or restrict exposure.

Timeline

1. 2026-08-09 03:40 UTC ReservedThe CVE id was reserved by its CNA
2. 2026-08-15 06:22 UTC PublishedDisclosed publicly on CVE.org and NVD
3. 2026-10-16 19:17 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.6% in the next 30 days (EPSS).
• Severity: 9.8 CRITICAL (CVSS).
• Fix: none linked yet, which raises it.

Details

Published

2026-08-15 06:22 UTC

Last modified

2026-10-16 19:17 UTC

Exploit probability

0.6% · EPSS, next 30 days

Record status

Received

Attack profile CVSS 3.1 · 9.8

Attack vector

Network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-72317.md and follow it. Check whether this project is affected by CVE-2026-72317. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge