CVE-2026-68082 in Linux
Summary
by MITRE • 08/08/2026
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix two unsafe bare decodes in decode_lockers()
decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads:
1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count.
The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant.
2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field.
Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers)
The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers().
err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed.
ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error.
-EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths.
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).
[ idryomov: trim changelog, formatting ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/08/2026
The vulnerability resides within the Linux kernel's ceph client implementation, specifically in the libceph library where the decode_lockers() function processes data received from OSDs. This flaw represents a critical security issue that enables remote code execution through out-of-bounds memory reads. The vulnerability stems from two distinct unsafe bare decode operations that lack proper bounds checking, creating opportunities for malicious actors to manipulate memory access patterns and potentially influence kernel behavior.
The first vulnerability occurs at the num_lockers field where ceph_decode_32(p) is executed without verifying buffer boundaries. When ceph_start_decoding() accepts struct_len=0 as valid input, it returns a pointer that equals the end of the buffer, causing the subsequent bare decode operation to read four bytes beyond the validated memory region. This garbage value gets directly passed to kzalloc_objs() as a locker count parameter, potentially leading to heap corruption or information disclosure through slab out-of-bounds reads. The issue is particularly concerning because it violates fundamental security principles regarding input validation and memory safety.
The second vulnerability manifests after the decode_locker() loop when ceph_decode_8(p) executes without bounds checking. If an OSD crafts a specific num_lockers value that advances the pointer exactly to the buffer end, this bare operation reads one byte past the validated boundary. This single byte read directly influences the lock type field used by callers for discriminator logic, providing attackers with direct control over critical kernel data structures and potentially enabling privilege escalation or denial of service conditions.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories, representing a classic buffer overflow scenario where insufficient bounds checking allows memory access beyond intended boundaries. The flaw also maps to ATT&CK technique T1059 Command and Scripting Interpreter and T1499 Endpoint Denial of Service, as it enables remote attackers to cause system instability or compromise kernel integrity.
The fix implements safe decode variants that incorporate proper bounds checking mechanisms. By replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, num_lockers, err_inval) and ceph_decode_8(p) with ceph_decode_8_safe(p, end, type, err_free_lockers), the implementation ensures that all memory accesses remain within validated buffer boundaries. The distinct error handling paths maintain proper resource management where err_inval handles pre-allocation failures without attempting to free uninitialized memory, while err_free_lockers manages post-allocation cleanup scenarios.
The attacker model focuses on compromised or malicious OSDs within multi-tenant Ceph deployments, which provides a realistic threat scenario given that OSDs typically operate with elevated privileges and can directly influence kernel client behavior. Any kernel client that issues lock.get_info class methods, particularly during RBD exclusive lock acquisition, becomes vulnerable to this attack vector. The vulnerability affects systems using the ceph client library and demonstrates the critical importance of proper input validation in kernel space code where malformed data from untrusted sources can lead to severe security consequences.
This fix addresses fundamental security requirements for kernel memory safety while maintaining compatibility with existing system functionality. The implementation follows established patterns used elsewhere in the same codebase, such as decode_watchers() in osd_client.c that already employs safe variants, ensuring consistency and reducing regression risks. The error handling design properly distinguishes between allocation failures and validation errors, preventing incorrect error propagation that could mask underlying security issues and complicate debugging efforts for system administrators and security researchers.