GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SUNRPC: use-after-free of the lower transport when a TLS handshake cancel races completion

UnscoredCVE-2026-89536Kernel, userspace & hypervisorcurated

Impact

On an RPC-with-TLS mount, a handshake that times out or is interrupted by a signal can drop a reference that the completion callback still owns, freeing the lower transport while xs_tls_handshake_done() is still writing to it. The result is a use-after-free in the storage path of the host kernel, which on a GPU node means a kernel oops or worse on the machine holding running training jobs. Nodes that mount TLS-protected NFS for dataset or checkpoint traffic hit this path on every handshake that does not complete cleanly, so a flaky or slow handshake peer widens the window. Exposure is limited to fleets that actually enable RPC TLS; plain NFS mounts do not reach this code.

Who can reach it

No authentication of an attacker is required in the usual sense: the race is driven by handshake timeouts or signals against a TLS-enabled RPC mount, so a peer or network condition that stalls the handshake, or any local process that interrupts a mount, can drive it. It is not a remotely controllable primitive on its own.

What to do

Take the stable kernel update carrying the fix (commits linked in the record); there is no runtime mitigation short of not using RPC TLS. Applying it means installing the patched kernel and rebooting each node, so plan a drain-and-reboot pass across the fleet rather than a live fix.

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.