GHSA-PRF2-R76G-87FC
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-19 18:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-68160"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:20:02Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()\n\nceph_handle_caps() reads snap_trace_len from the wire-format\nceph_mds_caps header and uses it unconditionally to build a fake\nend pointer (snaptrace + snaptrace_len) that is later handed to\nceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:\n\n snaptrace = h + 1;\n snaptrace_len = le32_to_cpu(h-\u003esnap_trace_len);\n p = snaptrace + snaptrace_len;\n ...\n case CEPH_CAP_OP_IMPORT:\n if (snaptrace_len) {\n ...\n if (ceph_update_snap_trace(mdsc, snaptrace,\n snaptrace + snaptrace_len,\n false, \u0026realm)) { ... }\n\nceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm\nfrom snaptrace using ceph_decode_need(\u0026p, e, sizeof(*ri), bad)\nwith the attacker-supplied fake end e == snaptrace + snaptrace_len.\nWith snaptrace_len == 0xFFFFFFFF the bound check is trivially\nsatisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past\nthe legitimate msg-\u003efront buffer, and ri-\u003enum_snaps /\nri-\u003enum_prior_parent_snaps then drive further out-of-bounds\nreads of the encoded snap arrays.\n\nThe eleven msg_version \u003e= 2 .. msg_version \u003e= 12 decoder blocks\nabove the op switch each catch this OOB through their\nceph_decode_*_safe() / ceph_decode_need() helpers, but they sit\nbehind a hdr.version-gated if, so a malicious or compromised\nMDS that sets msg-\u003ehdr.version = 1 reaches the IMPORT path with\nno version-gated decoder having validated snap_trace_len. The\nshape has been present since ceph_handle_caps() was introduced.\n\nValidate snap_trace_len against the message front buffer before\nconsuming it, using the canonical ceph_decode_need() / ceph_has_room()\nhelper. The helper bounds the length with subtraction (n \u003c= end - p,\nguarded by end \u003e= p) rather than pointer addition, so it is wrap-safe\nfor the attacker-controlled u32 length on 32-bit builds where\np + snap_trace_len could overflow the address space. This matches the\nrest of the ceph decode path (e.g. the pool_ns_len check a few lines\nbelow), and the existing goto bad cleanup already covers this exit\npath.",
"id": "GHSA-prf2-r76g-87fc",
"modified": "2026-08-19T18:32:08Z",
"published": "2026-08-10T15:33:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68160"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03b417afce19ee6b6e61f1bbbbebac924c9f36d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c011137194036424e974677e0f1592e22a33d8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71893c342a26bcff92eaab0b2b75d64aed19308a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9081c71796724ffe96cba253f68fbe42363c5295"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4228b93706fb74a484e6ffb271c1cc2af3a2ddb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc93f68a31c9b831abf2db8647b5f5b10329d793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f913192fc782288e060dafc329b2346934be34cc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.