Description

In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:51.283Z",
  "pubdate": "2026-09-11T20:19:51.283Z",
  "executiveSummary": "The Linux kernel Ceph file system client contains a slab out-of-bounds write vulnerability located in the NFS export functionality.\nThe vulnerability arises due to insufficient validation of dentry name lengths provided by the Metadata Server (MDS) during the get_name process.\nA malicious or compromised MDS can send a crafted LOOKUPNAME reply with a dname_len exceeding the NAME_MAX buffer constant, leading to an out-of-bounds write operation.\nThis flaw impacts systems where a CephFS mount is re-exported via NFS, potentially allowing an attacker to corrupt kernel memory.\nSuccessful exploitation requires the attacker to have control over the MDS or the ability to influence the metadata returned to the NFS client.\nThe impact is significant, as it can lead to system instability, denial of service, or potential arbitrary code execution within the kernel context, as identified by KASAN.",
  "technicalDetails": "The root cause of the vulnerability is the lack of bounds checking within the ceph_get_name() and __get_snap_name() functions in the Ceph client. When a client performs an NFS export get_name operation, the kernel expects the MDS to provide a dentry name. The current implementation copies this name into a fixed-size buffer of length NAME_MAX using memcpy(name, rinfo->dname, rinfo->dname_len).\nFollowing the memcpy operation, the code performs a null-terminator write at name[rinfo->dname_len] = 0. Because rinfo->dname_len is not validated against the destination buffer size (NAME_MAX), a malicious MDS can specify a length greater than the buffer's capacity. This results in a slab out-of-bounds write, which overwrites adjacent memory structures in the kernel heap.\nThe attack flow begins when an NFS client requests a name lookup for a file or directory on a CephFS mount. The client sends a request to the Ceph MDS. If the MDS is malicious, it responds with a LOOKUPNAME reply containing an abnormally large dname_len field. The client-side kernel module, failing to verify the length of the incoming data, performs the memcpy and subsequent null-write, resulting in the out-of-bounds write on the slab allocator.\nThis vulnerability is specifically reachable during the re-export of CephFS via NFS. The __get_snap_name() function exhibits a similar pattern, where it processes rde->name and rde->name_len without adequate validation, replicating the memory corruption risk during snapshot-related name retrieval.\nThe use of KASAN (Kernel Address Sanitizer) during testing confirms the existence of this memory safety violation. An attacker capable of influencing the MDS response can target this path to corrupt kernel objects, potentially hijacking kernel control flow or crashing the system to trigger a denial of service. The vulnerability underscores the danger of trusting metadata received from network-based file system servers without implementing strict input validation and length enforcement at the client level."
}