CVE-2026-68160: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()

CVE-2026-68160: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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

ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()

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.

The Linux kernel CVE team has assigned CVE-2026-68160 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.34 with commit a8599bd821d084d04a3290fffae1071624ec00ea and fixed in 6.6.148 with commit 9081c71796724ffe96cba253f68fbe42363c5295
	Issue introduced in 2.6.34 with commit a8599bd821d084d04a3290fffae1071624ec00ea and fixed in 6.12.101 with commit 03b417afce19ee6b6e61f1bbbbebac924c9f36d1
	Issue introduced in 2.6.34 with commit a8599bd821d084d04a3290fffae1071624ec00ea and fixed in 6.18.42 with commit a4228b93706fb74a484e6ffb271c1cc2af3a2ddb
	Issue introduced in 2.6.34 with commit a8599bd821d084d04a3290fffae1071624ec00ea and fixed in 7.1.6 with commit 71893c342a26bcff92eaab0b2b75d64aed19308a
	Issue introduced in 2.6.34 with commit a8599bd821d084d04a3290fffae1071624ec00ea and fixed in 7.2-rc5 with commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-68160
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ceph/caps.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9081c71796724ffe96cba253f68fbe42363c5295
	https://git.kernel.org/stable/c/03b417afce19ee6b6e61f1bbbbebac924c9f36d1
	https://git.kernel.org/stable/c/a4228b93706fb74a484e6ffb271c1cc2af3a2ddb
	https://git.kernel.org/stable/c/71893c342a26bcff92eaab0b2b75d64aed19308a
	https://git.kernel.org/stable/c/4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02