CVE-2026-68082 Overview
CVE-2026-68082 is an out-of-bounds read vulnerability in the Linux kernel's libceph client, specifically in the decode_lockers() function within cls_lock_client.c. The flaw stems from two bare decode operations that skip bounds checks after ceph_start_decoding() accepts a struct_len=0 value. A malicious or compromised Object Storage Daemon (OSD) in a multi-tenant Ceph deployment can send crafted responses to any kernel client that issues the lock.get_info class method, such as during RBD exclusive lock acquisition. The result is a slab-out-of-bounds read that leaks memory contents and grants the attacker one-byte control over the lock type discriminator used by callers.
Critical Impact
A malicious Ceph OSD can trigger slab-out-of-bounds reads in the Linux kernel client and influence a lock type field via crafted decode_lockers() responses.
Affected Products
- Linux kernel libceph module (net/ceph/cls_lock_client.c)
- Kernel clients using RBD exclusive lock acquisition
- Any kernel consumer invoking the lock.get_info Ceph class method
Discovery Timeline
- 2026-08-08 - CVE-2026-68082 published to the National Vulnerability Database
- 2026-08-13 - Last updated in NVD database
Technical Details for CVE-2026-68082
Vulnerability Analysis
The decode_lockers() function in cls_lock_client.c performs two bare decode operations without bounds validation. The first, ceph_decode_32(p), reads the num_lockers field. Because ceph_start_decoding() accepts struct_len=0 as valid, the internal ceph_decode_need(p, end, 0, bad) check passes and returns success with p == end. The subsequent bare 32-bit decode then reads four bytes past the validated buffer boundary. The resulting garbage value flows directly into kzalloc_objs() as the locker count.
The second bare operation, ceph_decode_8(p), executes after the decode_locker() loop. If a hostile OSD crafts num_lockers such that the loop advances p exactly to end, the following byte read crosses the boundary. That byte is written into *type and used by callers as a lock type discriminator, giving the OSD one-byte OOB read leakage combined with direct influence over lock semantics.
The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe(); decode_lockers() was the only remaining site using the unsafe bare variant.
Root Cause
The root cause is missing length validation after a permissive ceph_start_decoding() call. The helper does not reject zero-length structures, so downstream bare decodes assume buffer bytes that were never validated.
Attack Vector
A malicious or compromised OSD in a multi-tenant Ceph deployment sends a malformed reply to the lock.get_info class method. Any kernel client that issues this call, including RBD clients performing exclusive lock acquisition, becomes vulnerable. The attack requires no authentication beyond the trust already extended to an OSD peer.
The upstream fix replaces 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 two goto targets are distinct: err_inval handles the pre-allocation failure without touching *lockers, while err_free_lockers releases allocated memory after the loop. The ret variable is set to -EINVAL before the safe 8-bit decode so bounds violations return the correct error instead of the stale 0 from a successful loop.
Detection Methods for CVE-2026-68082
Indicators of Compromise
- Kernel KASAN: slab-out-of-bounds reports referencing decode_lockers or cls_lock_client.c
- Unexpected -EINVAL returns from RBD exclusive lock acquisition on affected kernels
- Anomalous Ceph OSD replies containing zero-length lock structures for lock.get_info
Detection Strategies
- Enable KASAN on kernel test hosts to surface out-of-bounds reads in libceph code paths
- Audit Ceph cluster logs for OSDs returning malformed or zero-length cls_lock responses
- Track kernel versions across fleets and flag hosts running unpatched libceph builds acting as RBD clients
Monitoring Recommendations
- Monitor dmesg and syslog for KASAN, general protection fault, or oops events originating from net/ceph
- Correlate RBD client failures with the specific OSD peer that returned the response for attribution
- Alert on new or unauthorized OSDs joining multi-tenant Ceph clusters
How to Mitigate CVE-2026-68082
Immediate Actions Required
- Apply the upstream Linux kernel patches referenced in the kernel.org commit a54be593d0b7 and companion commit a109a5561152
- Prioritize patching kernel RBD clients that connect to multi-tenant or untrusted Ceph deployments
- Reboot affected systems after installing the updated kernel package
Patch Information
The fix replaces bare ceph_decode_32(p) and ceph_decode_8(p) calls in decode_lockers() with the bounds-checked ceph_decode_32_safe() and ceph_decode_8_safe() variants. It also introduces the err_inval label to return -EINVAL cleanly on pre-allocation failure and preserves err_free_lockers for post-allocation failures. Distribution vendors track the fix through the stable trees referenced above.
Workarounds
- Restrict RBD kernel clients to trusted, single-tenant Ceph clusters until the kernel is patched
- Use user-space RBD access through librbd where the affected kernel decode path is not exercised
- Enforce network segmentation between kernel clients and OSDs controlled by untrusted tenants
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
