CVE-2026-68082

In the Linux kernel, the following vulnerability has been resolved:

libceph: fix two unsafe bare decodes in decode_lockers()

decodelockers() in clslock_client.c contains two bare decode operations

that allow a malicious or compromised OSD to trigger slab-out-of-bounds

reads:

1. cephdecode32(p) at the num_lockers field has no preceding bounds

   check. cephstartdecoding() accepts struct_len=0 as valid -- the

   internal cephdecodeneed(p, end, 0, bad) always passes -- so when an

   OSD sends structlen=0, cephstart_decoding() returns success with

   p == end. The immediately following bare cephdecode32(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 decodewatchers() in osdclient.c already uses

   cephdecode32safe() after its own cephstart_decoding() call.

   decode_lockers() was the only site using the bare variant.

1. cephdecode8(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 cephdecode8(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:

  cephdecode32(p) -> cephdecode32safe(p, end, *numlockers,

                                           err_inval)

  cephdecode8(p)  -> cephdecode8_safe(p, end, *type,

                                          errfreelockers)

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 cephfreelockers().

  errfreelockers: 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 cephdecode8_safe() so that

errfreelockers returns the correct error code on bounds violation.

Without this, errfreelockers 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 ]