GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nfsd: dangling IDR entry to freed layout stateid when nfsd4_layout_setlease() fails

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

Impact

nfs4_alloc_stid() publishes a new layout stateid into the client's IDR before nfsd4_layout_setlease() runs. On the setlease failure path the stateid is freed straight back to the slab without idr_remove(), so the IDR keeps a pointer to freed memory; any later walker - the states_show debugfs path or client teardown - dereferences it. A second defect means the delayed fence work is not initialised on that path either. Operators running an in-kernel NFS server with pNFS layouts in front of a GPU fleet get a use-after-free in the file server process context: realistic outcomes are a server-side panic that stalls every mounted client, with memory corruption not excluded. A single nfsd node going down takes the dataset mounts for many GPU nodes with it.

Who can reach it

An NFS client that can request a pNFS layout from the server and cause nfsd4_layout_setlease() to fail (conflicting leases or opens on the same file). Requires an authenticated NFS mount; no local access to the server is needed.

What to do

Apply the stable-kernel fix, which hoists the ls_fence_work initialisation above the setlease call and replaces the manual cleanup with nfs4_put_stid(). This is a kernel update on the NFS server: package upgrade plus reboot of the file server, or failover first if the server is clustered. Disabling pNFS layout exports removes the path if a reboot cannot be scheduled. No vendor advisory beyond the kernel stable commits is present in the record.

References

Related entries

All Kernel, userspace & hypervisor 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.