Linux kernel NFSD: client use-after-free when the laundromat reaps close_lru open owners

CVSS 9.8CVE-2026-90037Kernel, userspace & hypervisorcurated

Impact

An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid and only a raw pointer to the nfs4_client. The laundromat drops nn->client_lock and calls nfs4_put_stid(), which reaches the client through cl_lock with nothing pinning it, so a concurrent force_expire_client() can free the client underneath - and __destroy_client() races the same way by walking clp->cl_openowners without cl_lock. This is a distinct path from the blocked-lock race (see CVE-2026-90036), driven by normal open/close traffic rather than locking. On a fleet where NFS serves datasets and checkpoints, corruption or a panic in the server halts every node mounting it. The 9.8/AV:N score is the kernel CNA's default; exploitation requires winning a teardown race, not a single remote request.

Who can reach it

Remote NFS clients performing ordinary open and close operations against an export, racing a client expiry. No account on the server host is required beyond being allowed to mount.

What to do

Take the stable-kernel update with the listed commits and reboot the NFS server nodes - the fix is in the in-kernel nfsd, so restarting userspace NFS services changes nothing. Schedule the reboot as a fileserver outage window. The record names no fixed distribution version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-90037 https://git.kernel.org/stable/c/2330b788d732f43668b965b3105b37ceb276dfea https://git.kernel.org/stable/c/83dd59ac1c3455c2c7d8ddb582d980a13199b9b3 https://git.kernel.org/stable/c/e57a9ed34ea8c17e831de59b8f1a6b2d80d347a1

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.