Skip to main content
VulnerabilityPublished Updated

CVE-2026-68082: Linux kernel · libceph: fix two unsafe bare decodes in decode_lockers()

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in c8ade01170a27d8ede0d761c255268af81e417f8 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 14:18 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 42% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in c8ade01170a27d8ede0d761c255268af81e417f8, a109a556115271ca7896dcda7b4b7e45e156c227, a54be593d0b749161b08a1e56189b2cb9114267a +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 8 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < c8ade01170a27d8ede0d761c255268af81e417f8
Fixed in
  • c8ade01170a27d8ede0d761c255268af81e417f8
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < a109a556115271ca7896dcda7b4b7e45e156c227
Fixed in
  • a109a556115271ca7896dcda7b4b7e45e156c227
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < a54be593d0b749161b08a1e56189b2cb9114267a
Fixed in
  • a54be593d0b749161b08a1e56189b2cb9114267a
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < 02430f6f729b297e803d0605871f0a670b4eafd6
Fixed in
  • 02430f6f729b297e803d0605871f0a670b4eafd6
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < 001835c599899ef1bd3506a815110a6374451554
Fixed in
  • 001835c599899ef1bd3506a815110a6374451554
LinuxLinuxAffected
  • ≥ d4ed4a530562881cc5225050e42d96034f405aae, < 89df5d71f83f8e2781286798fd8ae5e42cf5f1a7
Fixed in
  • 89df5d71f83f8e2781286798fd8ae5e42cf5f1a7

Description

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 ]

References

Community reviews

Loading reviews…