Skip to main content
VulnerabilityPublished Updated

CVE-2026-68160: Linux kernel · Out-of-bounds Read

Affects Linux kernelSource CVE Database V5

0

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

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 55% 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 f913192fc782288e060dafc329b2346934be34cc, cc93f68a31c9b831abf2db8647b5f5b10329d793, a4228b93706fb74a484e6ffb271c1cc2af3a2ddb +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 10 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
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < f913192fc782288e060dafc329b2346934be34cc
Fixed in
  • f913192fc782288e060dafc329b2346934be34cc
LinuxLinuxAffected
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < cc93f68a31c9b831abf2db8647b5f5b10329d793
Fixed in
  • cc93f68a31c9b831abf2db8647b5f5b10329d793
LinuxLinuxAffected
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < a4228b93706fb74a484e6ffb271c1cc2af3a2ddb
Fixed in
  • a4228b93706fb74a484e6ffb271c1cc2af3a2ddb
LinuxLinuxAffected
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < 71893c342a26bcff92eaab0b2b75d64aed19308a
Fixed in
  • 71893c342a26bcff92eaab0b2b75d64aed19308a
LinuxLinuxAffected
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < 9081c71796724ffe96cba253f68fbe42363c5295
Fixed in
  • 9081c71796724ffe96cba253f68fbe42363c5295
LinuxLinuxAffected
  • ≥ a8599bd821d084d04a3290fffae1071624ec00ea, < 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02
Fixed in
  • 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02

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.

References

Community reviews

Loading reviews…