GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: unbounded symlink target length lets a client force multi-MiB kmallocs per COMPOUND op

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

Impact

nfsd4_decode_create() accepted an unbounded cr_datalen for NF4LNK targets, so each CREATE op in a COMPOUND can pin a kmalloc up to the maximum RPC payload (several MiB) until compound teardown, even though the VFS later rejects the path with ENAMETOOLONG. A client that pipelines such compounds drives server kernel memory pressure and can degrade or kill the NFS service that a whole GPU cluster reads datasets and writes checkpoints through. The fix rejects cr_datalen of zero and anything above NFS4_MAXPATHLEN before allocating. Availability impact only.

Who can reach it

Any authenticated NFSv4 client that can mount the export with write access to some directory, i.e. any tenant node or pod holding a normal mount.

What to do

Deploy a kernel containing the length validation (stable commits 041f57056e5f, 45ec115cbfec, 895a485cd375, b24843ea3de1) and reboot the NFS server node. No configuration-level mitigation is documented; limiting which clients can mount the export is the only interim reduction.

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.