CVE-2026-68082: 
Linux Debian Analyse et atténuation des vulnérabilités

CVE-2026-68082 is a slab-out-of-bounds read vulnerability in the Linux kernel's libceph library, specifically in the decode_lockers() function within cls_lock_client.c. A malicious or compromised OSD (Object Storage Daemon) can craft messages to trigger two separate out-of-bounds reads, potentially disclosing sensitive kernel memory. The vulnerability affects Linux kernel versions from 4.9 onward, with fixes committed to stable branches (commits a54be593d0b7 and a109a556115271ca). It was published on August 8, 2026, with a CVSS category estimate of Medium (GitHub Advisory).

The root cause is missing bounds validation (CWE class: out-of-bounds read) before two bare decode operations in decode_lockers(). First, ceph_decode_32(p) at the num_lockers field lacks a preceding bounds check — when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end, and the subsequent bare decode reads 4 bytes past the validated buffer boundary; the garbage value is then passed directly to kzalloc_objs() as the locker count. Second, ceph_decode_8(p) after the decode_locker() loop has no bounds check — if an OSD crafts num_lockers to advance p exactly to end, the subsequent read goes one byte past the buffer boundary, with the result used directly as a lock type discriminator. The fix replaces both bare operations with their safe variants (ceph_decode_32_safe() and ceph_decode_8_safe()), consistent with the pattern already used in the sibling function decode_watchers() in osd_client.c (GitHub Advisory).

Successful exploitation allows a malicious or compromised OSD in a multi-tenant Ceph deployment to trigger slab-out-of-bounds reads of kernel memory on any client that issues the lock.get_info class method (e.g., during RBD exclusive lock acquisition). The primary impact is confidentiality — sensitive kernel memory contents may be disclosed to the attacker. Additionally, the garbage num_lockers value passed to kzalloc_objs() could cause abnormal memory allocation behavior, and the OSD-controlled lock type value could influence caller logic, potentially facilitating further attacks (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.00198 (approximately 0.2%), indicating a low probability of exploitation in the near term. No threat actor attribution is available, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires the attacker to control or compromise an OSD within the target Ceph cluster, limiting the attack surface to environments with untrusted or multi-tenant OSD nodes (GitHub Advisory).

1. Gain OSD control: Compromise or operate a malicious OSD node within a Ceph cluster that serves kernel clients (e.g., in a multi-tenant environment where OSD trust boundaries are not enforced).
2. Trigger lock.get_info: Wait for or induce a kernel client to issue the lock.get_info class method — this occurs naturally during RBD exclusive lock acquisition.
3. Craft malicious response (OOB read #1): Respond to the client's request with a crafted message containing struct_len=0 in the lock info response. This causes ceph_start_decoding() to return success with p == end, after which the bare ceph_decode_32(p) reads 4 bytes past the validated buffer boundary, leaking kernel slab memory as the num_lockers value.
4. Craft malicious response (OOB read #2): Alternatively, craft num_lockers such that the decode_locker() loop advances p exactly to end, causing the subsequent bare ceph_decode_8(p) to read one byte past the buffer boundary, leaking a byte of kernel memory into the lock type field.
5. Harvest disclosed memory: Observe the effects of the OOB-read values (e.g., via error responses, timing, or side channels) to infer sensitive kernel memory contents and use them to facilitate further attacks (GitHub Advisory).

• Logs: Kernel logs (dmesg) showing slab corruption warnings or KASAN/KFENCE reports related to decode_lockers() or cls_lock_client.c; unexpected -EINVAL errors returned during RBD lock acquisition.
• Network: Unusual or malformed Ceph OSD messages with struct_len=0 in lock info responses; OSD responses with crafted num_lockers values that do not match expected cluster state.
• Process Behavior: Abnormal memory allocation sizes passed to kzalloc_objs() during Ceph lock operations; unexpected kernel panics or memory errors on Ceph client nodes during RBD exclusive lock acquisition.

Apply the upstream kernel patches that replace bare decode operations with safe variants in decode_lockers(): commits a54be593d0b749161b08a1e56189b2cb9114267a and a109a556115271ca7896dcda7b4b7e45e156c227 on the stable kernel branches. As a workaround, restrict OSD access to trusted systems only and avoid multi-tenant Ceph deployments where OSD nodes may be controlled by untrusted parties. Monitor for suspicious OSD behavior or messages with abnormal struct_len values (GitHub Advisory).

Coverage of CVE-2026-68082 has been limited to automated vulnerability tracking platforms and aggregators such as VulDB, Vulners, and CVEFeed, as well as a brief mention in a Linux kernel CVE roundup blog post. No significant vendor statements or notable researcher commentary beyond the kernel commit message have been identified (GitHub Advisory).