CVE-2026-89540: sunrpc: init gssp_lock before publishing proc entry
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: init gssplock before publishing proc entry
createusegssproxyprocentry() publishes /proc/net/rpc/use-gss-proxy via proccreatedata() before initgsspclnt() runs mutexinit() on sn->gssplock. Once the dentry is linked under procsubdirlock it is immediately reachable from userspace, so a write that lands in the window drives setgsspclnt() into mutexlock() on a zero-initialized struct mutex.
createusegssproxyprocentry(net) proccreatedata("use-gss-proxy", ...) / dentry live / initgsspclnt(sn) mutexinit(&sn->gssplock) / too late /
writegssp() setgsspclnt(net) mutexlock(&sn->gssplock) / uninitialized / gssprpccreate(...) sn->gsspclnt = clnt mutexunlock(&sn->gssplock)
The window spans only the two statements between proccreatedata() returning and initgsspclnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. registerpernetsubsys() runs in preemptible context under pernetopsrwsem, so that preemption is possible, and the window widens on authrpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIGDEBUGMUTEXES the missing magic value trips a "lock used without init" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before initgsspclnt() re-zeroes owner can enter setgsspclnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt.
Fix by initializing sn->gssplock in sunrpcinitnet() so its lifetime matches the sunrpcnet it lives in. sn->gsspclnt is already NULL from the kzalloc that backs netgeneric storage, so the lazy helper is no longer needed; drop initgsspclnt(), its prototype, and the call from createusegssproxyprocentry(). sunrpc.ko is a build-time dependency of authrpcgss.ko, so sunrpcinitnet() has always run on every netns before any authgss pernet init can publish the proc entry.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix the race by calling mutex_init(&sn->gssp_lock) in sunrpc_init_net() so sn->gssp_lock is initialized before create_use_gss_proxy_proc_entry()/proc_create_data("use-gss-proxy", ...) makes the file reachable from userspace.
Linux kernel (sunrpc / use-gss-proxy proc entry) gssp_lock initialization order = Initialize sn->gssp_lock before publishing /proc/net/rpc/use-gss-proxy via proc_create_data()
Event History
Frequently Asked Questions
What conditions are required for this race to be reachable?
A userspace task must attempt to open and write /proc/net/rpc/use-gss-proxy after it is published but before gssp_lock is initialized. This requires the registering thread to be preempted in the small interval between proc_create_data() returning and init_gssp_clnt().
When is the exposure window more likely to occur?
The registration path runs in preemptible context under pernet_ops_rwsem, so preemption in the affected interval is possible. The window is wider during auth_rpcgss module loading.