CVE-2026-89652: ceph: bound copied dentry name length in NFS export get_name
In the Linux kernel, the following vulnerability has been resolved:
ceph: bound copied dentry name length in NFS export getname
cephgetname() copies the MDS-supplied name into the caller's NAMEMAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dnamelen) and then writes name[rinfo->dnamelen] = 0, without checking dnamelen against NAMEMAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dnamelen > NAMEMAX overflows the buffer. getsnapname() copies rde->name / rde->namelen the same unchecked way.
Impact: a malicious or compromised Ceph MDS overflows the NAMEMAX name buffer in a client's NFS-export getname path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.
Add cephexportcopyname(), which rejects lengths above NAMEMAX with -ENAMETOOLONG before the copy, and use it in both cephgetname() and getsnapname().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Ceph kernel NFS export get_name path so that __get_snap_name() and ceph_get_name() reject MDS-supplied dentry/snap name lengths above NAME_MAX (e.g., via ceph_export_copy_name()), bound the memcpy to NAME_MAX, and write the trailing NUL byte only after bounds checking; this prevents slab out-of-bounds writes when dname_len > NAME_MAX.
CephFS NFS export (client get_name path) ceph_get_name() / __get_snap_name() dentry name length handling = Reject lengths above NAME_MAX and ensure NUL termination within NAME_MAX
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
CephFS clients are exposed when their CephFS mount is re-exported over NFS and the NFS-export get_name path is reached. The issue depends on an MDS supplying an oversized name in a LOOKUPNAME reply.
What does an attacker need to exploit it?
An attacker would need to control, compromise, or otherwise cause a Ceph MDS to return a LOOKUPNAME reply whose dname_len exceeds NAME_MAX. A buggy MDS that produces such a reply can also trigger the out-of-bounds write.
What can be done if the fix cannot be applied immediately?
Avoid re-exporting CephFS mounts over NFS, which removes the stated reachable path. Restrict trust and access to Ceph MDS instances so untrusted or compromised MDS responses cannot reach clients.
How can this issue be detected?
The described failure is a slab out-of-bounds write in the client's NFS-export get_name path and was reported by KASAN. Investigation should focus on CephFS mounts re-exported through NFS and MDS LOOKUPNAME replies with name lengths greater than NAME_MAX.