CVE-2026-89540

What it actually does

A TOCTOU race in the Linux kernel SUNRPC GSS-proxy path publishes /proc/net/rpc/use-gss-proxy before gssp_lock is mutex_init()'d. A concurrent write in that window calls set_gssp_clnt() on a zero-filled mutex: debug kernels splat, production kernels can CMPXCHG-acquire it, allowing a second writer to tear down an in-use RPC client, leak the losing client, and corrupt kernel RPC state with high impact to confidentiality, integrity, and availability.

Why it matters to the business

A local low-privileged user can crash hosts or corrupt kernel NFS/RPCSEC_GSS state, interrupting file-sharing and RPC authentication. The CVE is not in CISA KEV, is not tied to ransomware, and has no known exploit maturity about 34 days after publication; still treat unpatched Linux NFS/GSS systems as a local availability and potential privilege-escalation risk until kernels are updated.

How an attack unfolds

An attacker with a local unprivileged account waits for auth_rpcgss load or net-namespace setup, when create_use_gss_proxy_proc_entry() links the proc dentry before init_gssp_clnt() initializes gssp_lock. If the registering thread is preempted in that two-statement window, a write to /proc/net/rpc/use-gss-proxy locks the uninitialized mutex. A second writer can then run set_gssp_clnt() concurrently, shut down the first RPC client while it is still in use, leak the other client, and leave kernel SUNRPC state corrupted or crashed.

How to fix it

Apply distribution or vendor kernel updates that initialize sn->gssp_lock in sunrpc_init_net() and remove init_gssp_clnt() from create_use_gss_proxy_proc_entry(). No package-specific fixed versions were supplied with this record, so follow the kernel stable/distro advisory for CVE-2026-89540. Until patched, limit untrusted local users, avoid loading auth_rpcgss where GSS proxy is unused, and restrict write access to /proc/net/rpc/use-gss-proxy. Rebuild custom kernels from a tree that contains the sunrpc gssp_lock lifetime fix.

How to confirm the fix worked

Confirm the running kernel changelog or source includes mutex initialization of gssp_lock in sunrpc_init_net() and no longer calls init_gssp_clnt() from create_use_gss_proxy_proc_entry(). Match installed kernel packages to the vendor advisory for CVE-2026-89540. On live systems, uname -r plus distro security tracker; for custom builds, inspect net/sunrpc for the early gssp_lock init and dropped lazy helper.

Typical attack path

1. Obtain local unprivileged access on a Linux host that uses SUNRPC/RPCSEC_GSS
2. Wait for auth_rpcgss module load or network-namespace registration that publishes use-gss-proxy
3. Race a write to /proc/net/rpc/use-gss-proxy before gssp_lock is initialized
4. Cause set_gssp_clnt() to operate on an uninitialized mutex and overlap a second writer
5. Induce RPC client teardown-while-in-use, client leak, kernel oops, or memory corruption

How to detect it

There are no public in-the-wild campaigns; look for evidence of the race rather than a named implant. Review dmesg/journalctl/kern.log around sunrpc or auth_rpcgss load and netns creation for DEBUG_MUTEXES 'lock used without init' splats, lockdep warnings, and oops/panic stacks in write_gssp, set_gssp_clnt, or gssp_rpc_create. Audit or fanotify writes to /proc/net/rpc/use-gss-proxy by unprivileged UIDs at those times. Memory-leak or UAF reports involving gssp_clnt after overlapping writes are consistent with successful races. Absence of these artifacts does not prove the host was never targeted.

• lock used without init
• /proc/net/rpc/use-gss-proxy
• write_gssp
• set_gssp_clnt
• gssp_rpc_create
• gssp_lock
• DEBUG_LOCKS_WARN_ON
• auth_rpcgss

What your security team should do

• Patch Linux kernels that ship SUNRPC/auth_rpcgss as soon as vendor builds with the gssp_lock init fix are available
• Inventory hosts that load auth_rpcgss or expose /proc/net/rpc/use-gss-proxy (NFS, RPCSEC_GSS, GSS proxy)
• Until patched, reduce local untrusted users and unnecessary auth_rpcgss use
• Hunt kernel logs for uninitialized-mutex warnings and sunrpc oopses around module or netns init
• Track distro advisories; this is not KEV and has no known in-the-wild exploit, but CVSS 7.8 local high-impact still warrants prompt patching