Description

In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T15:17:10.400Z",
  "pubdate": "2026-08-26T15:17:10.400Z",
  "executiveSummary": "A critical out-of-bounds (OOB) read vulnerability exists in the Linux kernel's libceph component, specifically within the decode_watchers() function.\nThe vulnerability originates from a missing bounds check when processing responses from OSDs (Object Storage Devices), allowing a malicious or compromised OSD to trigger a 4-byte read beyond the allocated buffer boundary.\nThis flaw can be exploited by a malicious actor capable of acting as an OSD in a multi-tenant Ceph environment to induce memory corruption or information disclosure on any kernel-based client executing the CEPH_OSD_OP_LIST_WATCHERS operation.\nSuccessful exploitation requires no additional privileges beyond the establishment of an OSD session.\nThe vulnerability highlights a failure in input validation during network message parsing, which directly impacts the integrity and stability of the client-side kernel memory handling.",
  "technicalDetails": "The vulnerability resides in the decode_watchers() function within the libceph module of the Linux kernel. The root cause is an improper handling of struct_len values provided by an OSD during the decoding of an obj_list_watch_response_t structure.\nWhen a Ceph client initiates a CEPH_OSD_OP_LIST_WATCHERS request, it expects a response containing watchers data. The existing decoding pattern utilizes ceph_start_decoding(), which confirms that the remaining buffer length is at least the value specified in the header. However, if the header specifies struct_len=0, the macro ceph_decode_need() effectively validates that zero bytes remain, resulting in the pointer 'p' being set equal to the 'end' of the buffer.\nThe subsequent call to ceph_decode_32(p) lacks any secondary bounds validation to ensure that the 4-byte integer being read is within the current memory segment. Because 'p' is already equal to 'end', this operation results in an out-of-bounds read of 4 bytes beyond the allocated buffer. The retrieved garbage value is then passed as the watcher count argument to the kzalloc_objs() function.\nThe attack flow follows a predictable pattern: 1) The attacker, operating a malicious or compromised OSD, intercepts or initiates an OSD session with a legitimate Linux kernel client. 2) The client issues a CEPH_OSD_OP_LIST_WATCHERS command. 3) The attacker responds with a specially crafted obj_list_watch_response_t payload where struct_len is explicitly set to 0. 4) The client's kernel, upon parsing this header, erroneously concludes that decoding is successful but leaves the read pointer at the end of the buffer. 5) The decode_watchers() function proceeds to read 4 bytes of kernel memory immediately following the buffer. 6) The resulting value is utilized by the client to allocate memory via kzalloc_objs(), potentially leading to heap-based memory corruption, kernel crashes, or controlled information leakage if the resulting object allocation is manipulated.\nThis vulnerability is distinct from sibling functions like decode_watcher(), which correctly utilize safe variants such as ceph_decode_32_safe. The oversight in decode_watchers() makes it the primary vector for this OOB read attack."
}