GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sunrpc: svc_sock freed while the TLS handshake callback is still writing to it

CVSS 9.8CVE-2026-72222Kernel, userspace & hypervisorcurated

Impact

svc_tcp_handshake() hands the raw svc_xprt pointer to the handshake core, which only holds a reference on the socket - nothing pins the enclosing svc_sock that the callback reaches through container_of(). Two close races let svc_sock_free() kfree the structure while svc_tcp_handshake_done() is still running: svc_sock_free() ignores the tls_handshake_cancel() return value, and the cancel-loser path in svc_tcp_handshake() returns without draining. The commit message is explicit that the result is set_bit/clear_bit read-modify-write into a freed slab slot and complete_all() walking a freed wait_queue_head_t - a slab-corruption primitive, not a benign read. Reachable on any TLS-enabled NFS server when a connection close overlaps the tlshd downcall; signal delivery suffices. This is a distinct defect from the cancellation-ordering bug fixed alongside it, with its own commits.

Who can reach it

An unauthenticated client with network reach to a TLS-enabled RPC/NFS server that can open connections and close them during the handshake window. No credentials required.

What to do

Apply the stable-kernel fix, which takes svc_xprt_get() before tls_server_hello_x509() and releases it on the submission-failure, successful-cancel and callback-tail edges. Kernel update plus reboot on each NFS/RPC server; failover first if clustered. Turning off xprtsec/TLS removes the path at the cost of wire encryption. No vendor advisory beyond the kernel stable commits is present in the record.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.