CVE-2026-90037: NFSD: Prevent client use-after-free during close_lru reaping
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent client use-after-free during closelru reaping
An nfs4openowner left on nn->closelru after its final CLOSE keeps its last closed stateid in oolastclosedstid, holding only a raw pointer to its nfs4client. The laundromat reaps timed-out entries, drops nn->clientlock, and calls nfs4putstid(), which dereferences the client through cllock. Nothing pins the client across that window, so a concurrent forceexpireclient() can free it and nfs4putstid() reads freed memory. destroyclient() hits the same race, walking clp->clopenowners without cllock.
Pin the client with clrpcusers before dropping clientlock, and skip clients already expiring. destroyclient() then cleans up its own closelru entries through releaselastclosedstateid(), so teardown no longer races the laundromat.
Event History
Frequently Asked Questions
What conditions are required for this race to occur?
An NFSv4 open owner must remain on the NFSD close_lru after its final CLOSE, and the laundromat must reap that timed-out entry while another path concurrently force-expires or destroys the associated NFS client.
Which systems are realistically exposed?
Systems using the Linux kernel NFSD NFSv4 server code are implicated. The issue is in server-side client and close_lru cleanup rather than an NFS client-side path.
What should operators do if they cannot immediately apply the fix?
The provided information does not identify a configuration workaround. Reducing exposure would require avoiding the affected NFSD NFSv4 server functionality until a kernel containing the referenced fix is deployed.