GPU VulnDB

Database/Control plane, storage & DevOps

nfs-utils rpc.statd: memory leak on state notification requests lets a remote attacker exhaust node memory

CVSS 5.9CVE-2026-89096Control plane, storage & DevOpscurated

Impact

rpc.statd leaks memory allocated during callback processing for every state notification request it handles, so an unauthenticated attacker who can reach the service can drive its resident size up until the service degrades or the node runs out of memory. On GPU fleets this matters where rpc.statd is running on NFS clients or servers that back model, dataset and checkpoint storage: memory pressure on a shared NFS server stalls I/O for every training job pointed at it, and OOM pressure on a GPU node can take down long-running jobs that are expensive to restart. Impact is availability only - no data is read or modified. Exposure depends entirely on whether rpc.statd is reachable, which it usually is only on the storage VLAN.

Who can reach it

Anyone able to send RPC traffic to an exposed rpc.statd port, with no authentication. In practice that means a host on the storage or management network, or any tenant workload if the NFS/statd ports are not firewalled off from pod networks.

What to do

Install the updated nfs-utils for your distribution and restart rpc.statd (nfs-server/rpc-statd units); no reboot or node drain is needed, though in-flight NLM lock state recovery is briefly interrupted. Until patched, restrict rpc.statd to the storage network with host and fabric firewall rules. Red Hat tracks the fix per RHEL and OpenShift stream in its CVE page; the record given here does not name fixed package versions, so check that advisory for the build that applies to your release.

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.