Description

In the Linux kernel, the following vulnerability has been resolved: libceph: fix multiple unsafe decodes in decode_locker() decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T15:17:11.007Z",
  "pubdate": "2026-08-26T15:17:11.007Z",
  "executiveSummary": "The Linux kernel's libceph implementation contains multiple memory safety vulnerabilities within the decode_locker() function in cls_lock_client.c.\nThese vulnerabilities allow a malicious or compromised Object Storage Device (OSD) to trigger slab-out-of-bounds reads during the processing of Ceph class method responses.\nThe issue arises from the use of unsafe pointer arithmetic and decoding operations that lack proper input bounds validation.\nAn attacker with the ability to act as an OSD in a multi-tenant Ceph deployment can exploit this flaw to cause memory corruption, information disclosure, or kernel panics.\nSuccessful exploitation requires no additional privileges beyond the ability to establish an OSD session.\nThis vulnerability is critical in environments where trust in the storage backend (OSD) is not absolute, as it directly impacts the stability and security of kernel-based Ceph clients.",
  "technicalDetails": "The vulnerability is located in the decode_locker() function within the libceph component of the Linux kernel, specifically within the cls_lock_client.c file. The root cause is the reliance on unchecked pointer arithmetic and raw decoding operations when parsing locker information sent by an OSD.\nThe flaws identified include: First, an unsafe ceph_decode_copy() operation on the locker_id_t name field lacks a preceding bounds check. When the internal pointer 'p' aligns with the buffer end 'end', this operation reads 9 bytes of memory (sizeof(ceph_entity_name)) beyond the allocated buffer boundary.\nSecond, the function performs an unchecked pointer advance (*p += sizeof(struct ceph_timespec)) following the header of locker_info_t. An attacker can manipulate the OSD response to force 'p' past the 'end' pointer. Once this threshold is crossed, subsequent bounds-checking macros assume an invalid, 'p-past-end' state, effectively bypassing all security checks in the remainder of the decoding process.\nThird, the decoding of the length field via ceph_decode_32(p) lacks bounds verification. By sending a malicious length value (e.g., 0xffffffff), an attacker can trigger an arbitrary pointer advancement. This allows the pointer 'p' to skip gigabytes of memory, escaping the intended decode window entirely.\nThe attack flow involves a compromised or malicious OSD responding to a lock.get_info class method request—commonly triggered during RBD exclusive lock acquisition—with a crafted, malformed payload. By exploiting these unchecked operations, the OSD forces the kernel client to perform out-of-bounds reads from heap memory.\nThis behavior results in the disclosure of sensitive kernel memory to the OSD or, alternatively, triggers a slab-out-of-bounds read error that causes a kernel panic, leading to a Denial of Service (DoS) for the client. The use of unsafe functions like ceph_decode_copy and raw pointer increments facilitates this memory corruption, requiring the replacement of these primitives with safe, bounds-aware equivalents like ceph_decode_copy_safe and ceph_decode_skip_n."
}