Look up another CVE · open CVE-2026-68160 in the interactive tracker
CVE-2026-68160
ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem fs/ceph. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-68160 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/ceph/caps.c
- What this is
- CEPH DISTRIBUTED FILE SYSTEM CLIENT (CEPH)MAINTAINERS section matched on fs/ceph/ · ceph-devel@vger.kernel.org · Supported
- Kernel module
- ceph
Check it on the machine
grep -w CONFIG_CEPH_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w cephPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_CEPH_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.77%, higher than 54.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/ceph
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.34 | 5.10.265 | f913192fc782 |
| 2.6.34 | 5.15.216 | 0c0111371940 |
| 2.6.34 | 6.1.183 | cc93f68a31c9 |
| 2.6.34 | 6.6.148 | 9081c7179672 |
| 2.6.34 | 6.12.101 | 03b417afce19 |
| 2.6.34 | 6.18.42 | a4228b93706f |
| 2.6.34 | 7.1.6 | 71893c342a26 |
| 2.6.34 | 7.2 | 4dbc71bcaf9a |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- CEPH_MSG_CLIENT_CAPS is received over the kernel Ceph messenger TCP connection from an MDS peer; mds_dispatch() passes it directly to ceph_handle_caps(), so a malicious or compromised MDS (or on-path attacker on an unsigned msgr session) reaches the bug with network data alone.
- AC:LAttack complexity, low
- The attacker fully controls msg->hdr.version and snap_trace_len in the caps header; setting version=1 bypasses all version-gated decoders and snap_trace_len=0xFFFFFFFF yields a fake end pointer that reliably defeats ceph_decode_need(), with no race or memory-layout dependency.
- PR:NPrivileges required, none
- Exploitation requires only the ability to send crafted caps messages as the remote MDS peer on an established session; the attacker needs no account, mount privilege, or other credentials on the victim host beyond the client already being connected to that cluster.
- UI:NUser interaction, none
- Once CephFS is mounted and the MDS session is open, CEPH_CAP_OP_IMPORT caps messages are delivered and processed automatically during normal cap migration and MDS failover; no additional local user action is needed at exploit time beyond prior cluster connectivity.
- S:UScope, unchanged
- The out-of-bounds read and resulting snap-realm corruption affect only the kernel CephFS client’s internal state within the same kernel security authority; there is no VM escape, sandbox breakout, or cross-authority boundary crossing.
- C:HConfidentiality impact, high
- ceph_update_snap_trace() decodes struct ceph_mds_snap_realm and snap arrays using an attacker-supplied fake end pointer, reading sizeof(*ri) and further attacker-influenced extents past the legitimate msg->front buffer into adjacent kernel memory without copying to userspace.
- I:HIntegrity impact, high
- Out-of-bounds kernel memory is interpreted as snap-realm metadata and copied via dup_array() into newly allocated kernel heap structures (realm->snaps, realm->prior_parent_snaps), corrupting authoritative snap state and providing a memory-corruption primitive that could be leveraged for further kernel compromise.
- A:HAvailability impact, high
- Out-of-bounds reads can fault on unmapped pages causing a kernel oops; the ceph_update_snap_trace() error path issues WARN(1), fences I/O via CEPH_MOUNT_FENCE_IO, and can close all MDS sessions—effects an attacker can trigger repeatedly at will.