ZeroHour

CVE-2026-89649

moderate

Kernel heap info leak via unchecked xattr length in Linux CephFS client

CVSS 3.1
9.1 critical
EPSS
Published
()
Modified
AI analysis

The Linux kernel's CephFS client contains an out-of-bounds read in __build_xattrs(), which decodes extended attributes from a blob supplied by the Ceph metadata server (MDS). The value length of the final attribute is never validated against the actual blob size, so a malicious or compromised MDS can declare an oversized value length that __set_xattr() stores verbatim; a subsequent getxattr(2) then memcpy's past the end of the heap allocation, disclosing adjacent kernel heap memory to an unprivileged local user. Any host mounting a CephFS filesystem from an attacker-controlled or compromised metadata server is affected, and the issue is rated critical (CVSS 9.1) due to network attack vector, no required privileges, and high confidentiality and availability impact. No public proof of concept is known and the flaw is not listed in CISA's KEV catalog, so exploitation in the wild is not indicated.

What to do: Update to a kernel containing the fix, which adds a ceph_decode_need() check so an out-of-bounds final xattr length fails the decode with -EIO instead of being stored. Only trust metadata servers you control: do not mount CephFS filesystems from untrusted or potentially compromised MDS hosts, and verify MDS daemon integrity if compromise is suspected. Audit local users' use of getxattr(2) on CephFS files for signs of heap-probing attempts.

Affected
Linux kernel (CephFS client)
Estimated exposure
moderateLikely thousands to tens of thousands of Linux hosts mounting CephFS (estimate) — Ceph is widely deployed in private-cloud and enterprise storage (e.g., OpenStack, Red Hat/SUSE storage), but CephFS clients are typically internal hosts and Ceph components are rarely internet-exposed, so only the subset of Linux hosts…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.

Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

In the news

No ingested article mentions this CVE yet.