Cloudanix VulnDB

CVE-2026-89652

Critical · 9.8

CVSS

9.8

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in how Linux copies file names from a storage cluster when those files are also shared over NFS could let a malicious storage server corrupt memory and potentially take control of the machine.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Unbounded memcpy of MDS-supplied dentry name into a NAME_MAX-sized stack buffer in ceph_get_name() and __get_snap_name(), followed by a terminating null write, produces a slab out-of-bounds write reachable only when CephFS is re-exported over NFS.

Why it matters to the business

Systems that mount CephFS and then share it via NFS risk kernel memory corruption, crashes, or potential remote code execution; the flaw is limited to this narrow configuration and carries low observed exploitation probability.

How an attack unfolds

An attacker who controls or compromises a Ceph MDS sends a LOOKUPNAME reply containing dname_len greater than NAME_MAX; when a client that has mounted the CephFS volume re-exports it over NFS, the kernel path ceph_get_name copies the oversized name without length validation, corrupting adjacent slab memory.

How to fix it

Upgrade the Linux kernel to a version containing the ceph_export_copy_name() helper that rejects lengths above NAME_MAX with -ENAMETOOLONG before any copy; apply the fix to both ceph_get_name() and __get_snap_name().

How to confirm the fix worked

Confirm the running kernel contains the patch that introduces ceph_export_copy_name and replaces the direct memcpy calls; reproduce a LOOKUPNAME reply with dname_len > NAME_MAX and verify -ENAMETOOLONG is returned without KASAN reports.

Typical attack path

  1. Compromise or impersonate a Ceph MDS server
  2. Configure the MDS to reply to LOOKUPNAME with dname_len > NAME_MAX
  3. Cause a client to mount the CephFS volume
  4. Re-export that volume over NFS from the client
  5. Trigger NFS get_name operations that invoke the vulnerable copy path

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for KASAN reports citing slab-out-of-bounds write with call traces through ceph_get_name or __get_snap_name; also look for unexpected -ENAMETOOLONG errors on NFS exports after the fix is deployed.

  • slab-out-of-bounds write.*ceph_get_name
  • KASAN:.*rinfo->dname_len
  • ceph_export_copy_name

What your security team should do

  • Identify all hosts that both mount CephFS and re-export it via NFS
  • Prioritize kernel updates on those hosts even though EPSS remains low
  • Temporarily disable NFS re-export of CephFS mounts until patches are applied
  • Monitor kernel logs for KASAN slab-out-of-bounds reports involving ceph

The record

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().

Affected packages

Ecosystem Package Introduced Fixed