ZeroHour

CVE-2026-89662

mass

Linux Kernel NFSD Lock Owner Use-After-Free During NFSv4 Client Teardown

CVSS 3.1
9.8 critical
EPSS
Published
()
Modified
AI analysis

A use-after-free race condition exists in the Linux kernel's NFS server (nfsd) client-teardown path: when DESTROY_CLIENTID is processed, __destroy_client() walks the client's lock-owner table and calls remove_blocked_locks() without holding a reference on the owner, while the per-network-namespace 'laundromat' can concurrently free that same owner, producing a NULL dereference in remove_blocked_locks(). A remote attacker able to act as an NFSv4 client against a server can trigger the race by creating a blocked lock whose lock owner is only referenced by that lock, then issuing DESTROY_CLIENTID, racing with the laundromat's reap cycle. The practical result is a kernel crash of the NFSD host (denial of service); the issue is rated CVSS 3.1 9.8 (network, no privileges, no user interaction), though the described failure mode is a NULL dereference rather than controlled memory corruption. Any Linux system running the in-kernel NFS server with NFSv4 stateful locking reachable by untrusted or semi-trusted networks is potentially affected. No public proof of concept is known and the flaw is not listed in CISA's KEV.

What to do: Apply your distribution's kernel update as soon as a build containing this fix is released (the patch makes __destroy_client() hold cl_lock, take a reference on and unhash each owner before calling remove_blocked_locks()). In the interim, restrict NFS (TCP/2049) at firewall boundaries to trusted client subnets, and disable or unload nfsd on hosts that do not need to export filesystems. Monitor dmesg/kernel logs for Oopses or panics referencing remove_blocked_locks or client teardown as an indicator of attempted triggering.

Affected
Linux kernel (nfsd/NFSD NFSv4 server)
Estimated exposure
mass≈100,000–300,000 internet-reachable NFS services (TCP/2049), plus a much larger internal-only population of NFS servers — Public internet-wide scans (e.g., Shodan) consistently show on the order of a couple hundred thousand devices with the NFS port 2049 open, and only hosts acting as kernel nfsd servers — not NFS clients — are affected.

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.

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

In the news

No ingested article mentions this CVE yet.