CVE-2026-68160

What it actually does

This vulnerability is an out-of-bounds read in the Linux kernel Ceph client code path that processes MDS capability messages. A malicious or compromised Ceph Metadata Server can send a crafted caps IMPORT message with an attacker-controlled snap_trace_len value and an older message header version so that normal decoder bounds checks are bypassed. The kernel then constructs a fake end pointer beyond the legitimate message buffer and attempts to decode snapshot realm data from memory outside the received packet. Depending on kernel build, memory layout, and runtime conditions, this can cause kernel memory disclosure within the decode path, kernel warnings or crashes, or denial of service of systems using CephFS.

Why it matters to the business

Organizations using Linux systems mounted to CephFS could experience instability, service interruption, or potential exposure of kernel memory if a Ceph Metadata Server is malicious, compromised, or if an attacker can impersonate one. The issue is newly published, not currently listed in CISA KEV, not known to be used in ransomware campaigns, and has no reported public exploit maturity in the supplied data; however, kernel-level parsing flaws in storage clients should still be prioritized where CephFS is used in production or multi-tenant infrastructure.

How an attack unfolds

An attacker first needs a position where they can control, compromise, or impersonate a Ceph Metadata Server that a vulnerable Linux Ceph client trusts. The attacker sends a crafted ceph_mds_caps message using a header version that avoids the later version-gated decoder validation and sets snap_trace_len to an excessively large value such as 0xFFFFFFFF. When the client processes a CEPH_CAP_OP_IMPORT operation, ceph_handle_caps() uses that untrusted length to define the apparent end of the snaptrace buffer. ceph_update_snap_trace() then treats memory beyond the legitimate message front buffer as valid encoded snapshot realm data and reads fields such as num_snaps and num_prior_parent_snaps, which can drive additional out-of-bounds reads. The practical result is most likely a kernel crash or client-side denial of service, with possible sensitive memory exposure depending on how decoded data is subsequently handled and observable.

How to fix it

Upgrade affected Linux kernels to a version containing the Ceph client fix that validates snap_trace_len against the actual message front buffer using wrap-safe bounds checks before decoding snaptrace data. Because no specific affected products or fixed package versions were supplied, obtain fixed kernel packages from the relevant Linux distribution, appliance vendor, or kernel maintenance branch. Where immediate patching is not possible, reduce exposure by avoiding CephFS mounts from untrusted networks, ensuring Ceph monitors and MDS nodes cannot be impersonated, restricting client-to-Ceph network access to trusted segments, rotating Ceph credentials if MDS compromise is suspected, and disabling or unmounting CephFS on systems that do not require it.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport for the Ceph snap_trace_len bounds check in ceph_handle_caps(). Validate both the installed package version and the active running kernel after reboot, since kernel package updates do not protect systems until the fixed kernel is booted. Inventory systems for active CephFS use by checking mounted filesystems, loaded ceph kernel modules, and Ceph client configuration. In test environments, a negative validation approach is to confirm malformed MDS caps messages are rejected without kernel warnings, KASAN findings, or client crashes. Also confirm network controls only allow Ceph clients to communicate with authorized Ceph monitor and MDS endpoints.

Typical attack path

1. Gain control of a Ceph Metadata Server, compromise the Ceph control plane, or position as a trusted/impersonated MDS for vulnerable CephFS clients.
2. Wait for or trigger a client interaction that causes Ceph capability handling on the vulnerable Linux kernel client.
3. Send a crafted ceph_mds_caps message with msg->hdr.version set to 1 and a malicious snap_trace_len value.
4. Use CEPH_CAP_OP_IMPORT so the vulnerable IMPORT path calls ceph_update_snap_trace() with attacker-influenced bounds.
5. Cause the kernel Ceph client to read beyond the legitimate message buffer, potentially resulting in kernel warnings, crash, denial of service, or memory exposure artifacts.

How to detect it

Look for evidence on Linux CephFS clients and Ceph infrastructure. On clients, review kernel logs, journalctl, dmesg, crash dumps, KASAN reports, and monitoring alerts for Ceph client faults, out-of-bounds reads, kernel oopses, or sudden reboots associated with CephFS activity. On Ceph servers, review MDS logs and audit records for unexpected MDS restarts, unauthorized configuration changes, unusual client sessions, suspicious capability traffic, or signs that an MDS host was compromised. Network telemetry may show abnormal or unexpected traffic between clients and MDS services, especially from nonstandard MDS addresses. Because this is a memory-safety parsing flaw and no public exploit indicators were supplied, detection should focus on behavioral evidence: malformed Ceph message handling, kernel crashes in Ceph client functions, and compromise indicators on MDS nodes.

• ceph_handle_caps
• ceph_update_snap_trace
• snap_trace_len
• CEPH_CAP_OP_IMPORT
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• ceph:
• libceph:
• mds caps
• snaptrace
• /sys/module/ceph
• /proc/fs/ceph
• /etc/ceph/ceph.conf

What your security team should do

• Prioritize patching Linux systems that mount CephFS, especially production storage clients, virtualization hosts, container platforms, and multi-tenant compute nodes.
• Inventory active CephFS usage across Linux fleets by reviewing mounts, loaded ceph modules, and Ceph configuration files.
• Treat any compromised or untrusted Ceph MDS as a potential client-compromise or client-denial-of-service source and investigate all connected clients.
• Restrict Ceph client traffic to trusted Ceph monitor, MDS, and OSD networks; block unauthenticated or unexpected systems from reaching Ceph service ports.
• Review kernel logs from CephFS clients for crashes, KASAN reports, or Ceph decode errors around the time of suspicious MDS activity.
• If MDS compromise is suspected, rotate CephX credentials, rebuild or validate MDS nodes, and remount clients only after patching and trust restoration.
• Track vendor advisories for exact fixed kernel versions because no per-package fixed versions were provided in the input.