GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sunrpc: use-gss-proxy proc entry published before its mutex is initialized

CVSS 7.8CVE-2026-89540Kernel, userspace & hypervisorcurated

Impact

create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy before init_gssp_clnt() initializes sn->gssp_lock, so a write landing in the two-statement window locks a zero-filled struct mutex. On a production kernel the fast path acquires it via cmpxchg, which lets a second writer enter set_gssp_clnt() concurrently, shut down the first writer's RPC client while it is still in use, and leak the loser's client. The window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. This matters on Kerberized NFS servers and clients in shared clusters; the fix moves the mutex init into sunrpc_init_net() so its lifetime matches the namespace.

Who can reach it

Local, privileged. Requires write access to /proc/net/rpc/use-gss-proxy (root in the namespace) timed against auth_rpcgss module load or pernet registration - a narrow race, not a drive-by.

What to do

Pick up a stable kernel with commit f15b87521168 or its backport and reboot. The exposure is limited to hosts that load auth_rpcgss (Kerberos NFS); nodes not using gssproxy can be deprioritized.

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.