CVE-2026-90036
largeUse-after-free in Linux kernel NFSD blocked-lock reaping
CVE-2026-90036 is a use-after-free in the Linux kernel's NFS server (NFSD) state management: a 'bare' lock owner whose only remaining reference is a blocked lock on the blocked_locks LRU holds a raw pointer to its nfs4_client without keeping the client alive. When the per-net laundromat reaps such a blocked lock, freeing the lock owner can make nfs4_put_stateowner() dereference the client's cl_lock, and because the laundromat detaches the lock first, a concurrent force_expire_client() can free the client before that call, touching freed memory. Triggering it requires NFS clients performing blocked-lock (NLM) operations while client expiry runs concurrently, which an attacker able to mount exports could attempt remotely. A successful exploit corrupts kernel memory in the NFS state machinery, with potential for denial of service and, per the CVSS 9.8 score, high confidentiality/integrity/availability impact. Any Linux system acting as an NFS server is potentially affected; no public proof-of-concept or in-the-wild exploitation is currently known.
What to do: Apply the upstream NFSD fix via your distribution's kernel update as soon as vendors ship it. In the meantime, restrict NFS access (TCP/UDP 2049) to trusted clients with firewall rules, avoid unauthenticated or broad exports, and check whether the NFS server service is enabled and whether any clients rely on blocked (NLM) locks. Not currently listed in CISA KEV and no public exploit is known.
| Linux kernel (NFSD / NFS server subsystem) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.