GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux sunrpc xprtsock: unannotated socket callback replace/restore leaves a stale-pointer race

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

Impact

xprtsock replaced and restored sk->sk_data_ready and sk->sk_write_space on live AF_LOCAL, UDP and TCP sockets with plain stores, and read sk_write_space with a plain load, while those pointers are shared with generic socket and protocol paths running on other CPUs. The window is that another CPU holding an earlier snapshot can invoke xs_data_ready() or xs_udp_write_space() after teardown has already restored the lower-socket handlers. The fix is an annotation change - WRITE_ONCE on the stores, READ_ONCE on the invocation - with no attacker-controlled input and no demonstrated exploit, so treat this as hardening of the NFS/RPC client transport rather than something to open a window for tonight. It matters mainly because sunrpc is in the path of the NFS mounts that carry datasets and checkpoints on most GPU clusters, where an RPC-teardown crash drains a node at an inconvenient moment. The NVD score of 9.8 network/unauthenticated is not supported by the commit messages.

Who can reach it

No attacker role is described. The race needs concurrent socket activity and RPC transport teardown on the same host, i.e. ordinary NFS client traffic; nothing in the record suggests a remote or local user can steer it.

What to do

Pick up the fix with your next stable kernel update - the five git.kernel.org commits listed are the backports across stable branches. A kernel change means draining each node and rebooting it, so fold this into regular maintenance rather than scheduling for it; no mitigation is needed or offered in the interim.

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.