GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: uncapped POSIX ACL entry count drives an O(n^2) sort in the NFS server

CVSS 7.5CVE-2026-89695Control plane, storage & DevOpscurated

Impact

nfsd4_decode_posixacl() took a client-supplied u32 entry count straight from the wire into posix_acl_alloc() and a bubble sort, so a single COMPOUND can burn unbounded CPU inside an nfsd kthread. On a shared dataset server this starves every other NFS client behind the same nfsd thread pool - which on a GPU fleet means training jobs stall on dataset and checkpoint reads across many nodes at once, not just the node that issued the request. The encoder side already enforced NFS_ACL_MAX_ENTRIES; the decoder omitted the symmetric check. Availability-only: no memory corruption or data disclosure is claimed.

Who can reach it

Any host that can mount the export and issue an NFSv4 COMPOUND. Standard NFS client authentication applies, so in practice any tenant node or pod with access to the storage VLAN, not an unauthenticated internet attacker.

What to do

Update the kernel to a build containing the fix (commits 4bc1108e8761 and ea14d71d6ecb in stable) and reboot the NFS server node. If the server is a dedicated storage head, this is one reboot with a client-visible pause; there is no module reload path for nfsd on a live export. Until then, restrict export access to known client subnets - no upstream mitigation is documented.

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.