Description
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.
Published: 2026-08-15
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel’s SUNRPC module, a use‑after‑free bug exists in the TLS connection setup path. When a TLS handshake fails, the code frees the upper rpc_clnt before a delayed connect_worker dereferences it. This results in a refcount underflow, which can corrupt kernel memory.

Affected Systems

All Linux kernel installations that implement the SUNRPC TLS connect worker and have not yet incorporated the patch from the referenced commit are affected. The vulnerability applies to any kernel version prior to the inclusion of the rpc_hold_client and rpc_release_client helpers; no specific version range is specified, so all current deployments lacking the fix are potentially vulnerable.

Risk and Exploitability

The CVSS score of 9.8 indicates critical severity, while the EPSS score of <1% and absence from the CISA KEV catalog suggest that exploitation is unlikely but still possible. Based on the description, it is inferred that an attacker would need to initiate a TLS‑backed SUNRPC connection that subsequently fails (for example, by providing an invalid client certificate). The likely attack vector is remote via network. If successfully exploited, the refcount underflow could lead to kernel memory corruption, which may result in denial of service or more severe effects if the attacker can trigger further kernel code execution.

Generated by OpenCVE AI on August 22, 2026 at 08:38 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the pending patch (implementation of rpc_hold_client and rpc_release_client).
  • If an immediate upgrade is not feasible, disable or prohibit TLS‑backed SUNRPC connections to eliminate the vulnerable execution path.
  • Apply network segmentation or firewall rules to restrict external access to services that could initiate SUNRPC TLS connections, reducing the exposure window.

Generated by OpenCVE AI on August 22, 2026 at 08:38 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 07:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 19 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 17 Aug 2026 17:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 10:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Sat, 15 Aug 2026 19:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Description 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.
Title SUNRPC: pin upper rpc_clnt across the TLS connect_worker
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:42:43.024Z

Reserved: 2026-08-09T03:40:39.919Z

Link: CVE-2026-72317

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:22:04.620

Modified: 2026-08-17T06:18:35.000

Link: CVE-2026-72317

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72317 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T08:45:03Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference