CVE-2026-68160

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

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

cephhandlecaps() reads snaptracelen from the wire-format cephmdscaps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptracelen) that is later handed to cephupdatesnaptrace() in the CEPHCAPOP_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)) { ... }

cephupdatesnaptrace() then decodes a struct cephmdssnaprealm from snaptrace using cephdecodeneed(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptracelen. With snaptracelen == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct cephmdssnaprealm) past the legitimate msg->front buffer, and ri->numsnaps / ri->numpriorparent_snaps then drive further out-of-bounds reads of the encoded snap arrays.

The eleven msgversion >= 2 .. msgversion >= 12 decoder blocks above the op switch each catch this OOB through their cephdecode*safe() / cephdecodeneed() 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 snaptracelen. The shape has been present since cephhandle_caps() was introduced.

Validate snaptracelen against the message front buffer before consuming it, using the canonical cephdecodeneed() / cephhasroom() 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 + snaptracelen could overflow the address space. This matches the rest of the ceph decode path (e.g. the poolnslen check a few lines below), and the existing goto bad cleanup already covers this exit path.