GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux CephFS client: unchecked dentry name length overflows a NAME_MAX buffer in the NFS re-export path

UnscoredCVE-2026-89652Kernel, userspace & hypervisorcurated

Impact

ceph_get_name() memcpy's an MDS-supplied name into a NAME_MAX-sized caller buffer without checking dname_len, and then writes a NUL one byte past it; __get_snap_name() copies rde->name the same way. An MDS that returns a LOOKUPNAME reply with an oversized name produces a slab out-of-bounds write in the client, reported by KASAN. On a GPU node this is a kernel-memory corruption in the storage path: the realistic outcome is a node crash that takes resident jobs with it, and corruption of adjacent slab objects cannot be ruled out. Exposure is narrow - the path is only reached when a CephFS mount is re-exported over NFS - so fleets that mount CephFS directly on compute nodes without re-export are not on this code path.

Who can reach it

Not reachable from a tenant pod. Requires a malicious or compromised Ceph MDS (or something able to forge MDS replies on the storage network) talking to a client that re-exports a CephFS mount over NFS.

What to do

Update to a stable kernel carrying the fix; four backport commits are linked on the record. A mounted kernel CephFS client cannot be swapped in place, so this is a drain and reboot per node - batch it with the other libceph/ceph fixes published the same day. As an interim mitigation, stopping the NFS re-export of CephFS removes the reachable path.

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.