GPU VulnDB

Database/Control plane, storage & DevOps

Linux nfsd: writing unlock_filesystem after server shutdown walks freed state tables (use-after-free)

UnscoredCVE-2026-89661Control plane, storage & DevOpscurated

Impact

Writing a filesystem path to /proc/fs/nfsd/unlock_filesystem runs nfsd4_cancel_copy_by_sb() before nfsd_mutex is held and before the handler confirms nn->nfsd_serv is set. After nfsd has shut down, nfs4_state_destroy_net() has freed nn->conf_id_hashtbl but left the pointer, so the helper iterates freed slab memory as list heads and then takes clp->async_lock on a bogus nfs4_client; KASAN reports a slab-use-after-free read. A local administrator with CAP_SYS_ADMIN reaches it by stopping the server and then writing to the file - so this is an admin-triggered crash of a storage or head node rather than a privilege boundary an unprivileged tenant can cross. Worth patching on any node that exports NFS to the fleet, but it does not warrant an emergency window on its own.

Who can reach it

Local administrator holding CAP_SYS_ADMIN on the NFS server host, writing to /proc/fs/nfsd/unlock_filesystem after nfsd has been stopped. No tenant or network path.

What to do

Update the NFS server host to a stable kernel carrying the fix (two backport commits linked on the record); the fix moves the async COPY cancel inside the section already guarded by nfsd_mutex with nn->nfsd_serv confirmed present. Remediation is a reboot of the server node - batch it with the other nfsd fixes from the same day. Until then, do not write to unlock_filesystem while nfsd is stopped.

References

Related entries

All Control plane, storage & DevOps entries

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.