KernelScan.io

HIGH Introduced in 3.10

sunrpc GsspLock Race

CVE-2026-89540

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.0HIGH

01

In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data("use-gss-proxy", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss 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 CONFIG_DEBUG_MUTEXES 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 init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.

02

Engine v0.6.0

Risk summary

Local attackers who can write to the GSS proxy proc file during a narrow race window when the authentication module is loading can cause use-after-free and memory corruption in the kernel. The vulnerability requires the sunrpc auth_gss module to be loaded and timing-sensitive access to the proc filesystem entry. Successful exploitation could lead to kernel memory corruption, information disclosure, or denial of service.

Affectednet/sunrpc/auth_gss/ (sunrpc GSS proxy authentication)

Vulnerability analysis

A race condition in the sunrpc GSS proxy authentication subsystem allows a local attacker to exploit a brief window during module loading where a proc filesystem entry becomes visible before its protecting lock is initialized. Writing the proc file during this window acquires an uninitialized lock, which on production kernels appears unlocked, allowing a second concurrent writer into the same critical section. This can cause one writer to shut down a shared client object while another is still using it, leading to use-after-free and memory corruption, or leaking kernel memory. The fix initializes the lock earlier during namespace setup so it is ready before the entry is exposed, and eliminates the separate late-init path. The vulnerability is reachable locally by writing to the proc file with the necessary namespace privileges; the race is easiest to hit while the authentication module is loading on a system with running tasks.

03

BranchIntroducedFixed inPatch commit
5.103.105.10.270159a4fab7170
5.153.105.15.221b3526ae33519
6.13.106.1.1887f5bcdc8da15
6.123.106.12.109f15b87521168
6.183.106.18.50edeefb111d61
6.63.106.6.15789c8e0733e8c
7.23.107.2.43f019571928b
mainline3.107.35ce1ed615973
cip/5.103.105.10.271-cip78159a4fab7170
cip/6.13.106.1.189-cip617f5bcdc8da15
cip/6.1-rt3.106.1.189-cip61-rt327f5bcdc8da15
cip/6.123.106.12.111-cip32f15b87521168

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.111-cip32
cip/6.1Fixed in 6.1.189-cip61
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Fixed in 5.10.271-cip78
cip/5.10-rtAffected — no CIP fix yet (latest 5.10.268-cip77-rt34)
cip/4.19Affected — no CIP fix yet (latest 4.19.325-cip136)
cip/4.19-rtAffected — no CIP fix yet (latest 4.19.325-cip136-rt50)
cip/4.4Affected — no CIP fix yet (latest 4.4.302-cip115)
cip/4.4-rtAffected — no CIP fix yet (latest 4.4.302-cip115-rt63)