CVE-2026-72317
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk48th percentile - higher than 48% of all known CVEs
Summary
In the Linux kernel SUNRPC subsystem, a use-after-free vulnerability exists in the TLS connect path. Nothing pins the upper rpc_clnt across the delayed connect_worker, which can lead to dereferencing freed memory when a TLS connection fails (e.g., mTLS error).
Risk Assessment
An attacker could trigger this vulnerability to cause a kernel crash or potentially escalate privileges by initiating a failed TLS connection (e.g., mounting with a bad certificate).
Recommendation
Apply the official Linux kernel patch that adds rpc_hold_client() and rpc_release_client() calls to pin the rpc_clnt. Update the system to a kernel version containing the fix.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98164Unknown
In the Linux kernel, KVM x86/mmu's kvm_gfn_is_write_tracked() only checks the supplied memslot, but page tracking is per-address-space and shadow pages are shared across address spaces. With SMM, a GFN can be write-tracked in one address space and appear untracked in another. The fix checks the supplied slot first, then the slot for the other address space, preventing mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and triggering a BUG in pte_list_remove().
- CVE-2026-98048Unknown
In the Linux kernel's BPF subsystem, mark_fastcall_pattern_for_call() must ensure that a matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is unsound. The fix records instructions targeted by jumps in insn_aux_data[*].jump_target and uses this flag to stop growing a pattern.
- CVE-2026-98047Unknown
In the Linux kernel's BPF subsystem, in_rbtree_lock_required_cb() only checks the innermost verifier frame, so rbtree callback restrictions disappear in a nested static subprogram call frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock, leading to freed memory being linked into the tree.
- CVE-2026-98046Unknown
In the Linux kernel's BPF subsystem, bpf_btf_find_by_name_kind() returns a new BTF object fd through __btf_new_fd(), which reaches anon_inode_getfd() that can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks.
- CVE-2026-98045Unknown
In the Linux kernel, a BPF verifier vulnerability affects stack helpers that may block on filesystem reads (e.g., resolving build IDs) but were not marked as sleepable. The verifier could still allow these helpers from non-sleepable regions such as RCU or preemption-disabled sections.
- CVE-2026-98044Unknown
In the Linux kernel, the BPF verifier mishandled legacy packet-load instructions (BPF_LD_ABS/BPF_LD_IND) reached from callbacks, triggering a verifier bug warning and an -EFAULT on BPF_PROG_LOAD. A privileged program loader could trigger this issue.
- CVE-2026-98043Unknown
In the Linux kernel, the BPF verifier incorrectly inferred that a pointer with an unbounded offset is non-NULL based solely on its type. As a result, a BPF program could pass verification while a NULL pointer dereference occurred at runtime.
- CVE-2026-98042Unknown
In the Linux kernel, the BPF verifier could resurrect a scalar id dropped by collect_linked_regs() because snapshots of compared registers were taken before linked registers were collected. This could lead to range inconsistencies and precision propagation issues.
- CVE-2026-98041High
In the Linux kernel, the BPF verifier incorrectly predicted the outcome of pointer vs zero comparisons in JMP32 instructions, failing to distinguish BPF_JMP from BPF_JMP32 comparisons. This led to incorrect inference that a jump is always taken.
- CVE-2026-98040Unknown
In the Linux kernel, the BPF verifier did not mark the zero register as precise for a register-form NULL check. As a result, one path was pruned and the program could dereference a zero pointer at runtime.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS