GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: NFSv4 compound decoding indexes the op table with OP_ILLEGAL, reading far out of bounds

CVSS 7.8CVE-2023-53680Control plane, storage & DevOpscurated

Impact

OPDESC() indexes nfsd4_ops[] by operation number without range checking, and the NFSv4 compound decoder could reach it with opnum set to OP_ILLEGAL (10044) - an index thousands of entries past the end of the array. An NFS client that sends a crafted compound with an illegal operation makes the server dereference whatever lies at that offset, which means an in-kernel out-of-bounds read and a likely panic. This is one of the few entries here that an attacker reaches over the network: for GPU fleets that mount datasets and checkpoints over NFS, a crash on the file server stalls every job on every node that depends on it, and recovery is a server reboot rather than a pod restart.

Who can reach it

Remote, from any host that can reach the NFS server's NFSv4 port and get far enough to send a compound request - so the exposure is whatever your export and firewall rules allow, typically the whole compute VLAN. No valid file access rights are needed to send a malformed compound. Only hosts running the in-kernel NFS server are affected; clients are not.

What to do

Update the NFS server hosts to a fixed stable kernel (commits in the record; fix landed in the 6.3 series and backports) and reboot them. That is a storage-server reboot with client I/O stalling through the outage, so sequence it with the jobs that mount those exports. Until patched, restrict NFSv4 reachability to known client subnets - there is no server-side setting that removes the bad index.

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.