CVE-2026-80557 in Linux
Summary
by MITRE • 08/26/2026
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 ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel contains a critical out-of-bounds read vulnerability within the Ceph distributed file system implementation, specifically located in the libceph subsystem's decode_watchers function. This flaw arises from an insufficient bounds check during the decoding of watch list responses sent by Object Storage Daemons to client kernels. The root cause lies in the ceph_start_decoding routine, which is responsible for validating that sufficient data remains in the buffer after parsing the encoding header. While this validation ensures that struct_len bytes are available, it erroneously accepts a value of zero as valid because the check always passes when no additional bytes are required beyond the header itself. Consequently, if an attacker-controlled or compromised OSD sends an obj_list_watch_response_t reply with a struct_len field set to zero, the decoding process returns success while leaving the buffer pointer at the end boundary, effectively guaranteeing that subsequent read operations will access memory outside the validated buffer limits.
The immediate operational impact of this oversight is triggered in decode_watchers when it attempts to retrieve the watcher count using ceph_decode_32 without any preceding bounds verification. Since the previous validation step allowed a zero-length structure payload, the pointer p equals end at this stage. Executing a standard 32-bit read operation under these conditions results in reading four bytes past the allocated buffer boundary into adjacent kernel memory space. This constitutes an out-of-bounds read vulnerability that can lead to information disclosure or potentially destabilize system stability depending on what data resides immediately after the buffer. The garbage value retrieved from this invalid memory location is then passed directly to kzalloc_objs as the number of watchers, which may cause further allocation anomalies if the kernel attempts to process a nonsensical count derived from unrelated memory contents.
From an attacker perspective, this vulnerability requires only that the adversary controls or compromises an OSD within a multi-tenant Ceph deployment such as a cloud infrastructure environment. The attack vector does not require elevated privileges beyond establishing a standard OSD session connection. By sending specifically crafted obj_list_watch_response_t messages with struct_len set to zero during CEPH_OSD_OP_LIST_WATCHERS operations, the attacker can trigger this out-of-bounds read against any kernel client interacting with that specific OSD instance. This highlights a significant risk in distributed storage architectures where trust boundaries between clients and storage nodes must be strictly enforced through rigorous input validation on all received data structures regardless of their apparent size or complexity.
The technical analysis reveals an inconsistency in the codebase's defensive programming practices. The sibling function decode_watcher correctly employs safe decoding variants such as ceph_decode_copy_safe, ceph_decode_64_safe, and ceph_decode_skip_32 after its own validation calls to ensure buffer integrity before accessing data fields. In contrast, decode_watchers relied on the bare variant of the 32-bit decoder function, indicating an oversight in applying consistent security patterns across similar code paths. The resolution involves replacing the unsafe ceph_decode_32 call with ceph_decode_32_safe, which incorporates explicit bounds checking against the end pointer before attempting to read data. This change aligns the implementation with established secure coding standards and prevents out-of-bounds access by ensuring that sufficient bytes remain in the buffer prior to any extraction operation.
This vulnerability maps directly to CWE-125 Out-of-Bounds Read, which describes accessing memory beyond the intended boundary of a buffer. In terms of offensive security frameworks, this flaw aligns with MITRE ATT&CK technique T1083 File and Directory Discovery, as an attacker could potentially use the leaked data for reconnaissance purposes within the host system. Mitigation strategies should prioritize applying the kernel patch that introduces the safe decoding variant immediately in production environments running affected Ceph clients. Additionally, organizations operating multi-tenant Ceph deployments should enforce strict network segmentation between client nodes and OSDs to limit exposure to compromised storage components. Regular auditing of input validation logic across all protocol parsing functions is recommended to prevent similar oversights where size checks fail to account for edge cases such as zero-length payloads that still require subsequent field extraction operations.