Linux Kernel libceph CVE-2026-68433

Exploitation requires that the Linux system is running as an active Ceph client with libceph loaded and a live connection to a Ceph monitor (i.e., an rbd device is mapped or a CephFS/Ceph block volume is mounted). The attacker must be capable of delivering a crafted or truncated MON_GET_VERSION_REPLY message to the kernel's libceph socket - achievable either by controlling a Ceph monitor endpoint the client trusts, or by intercepting the unencrypted Ceph messenger v1 protocol (port 6789) as a MITM. Ceph messenger v2 with encryption (port 3300, enabled by default in recent Ceph releases) substantially raises the bar for MITM exploitation. Systems not using Ceph storage (no libceph module loaded, no Ceph mounts) are entirely unexposed. Authentication via CephX secures the session setup but does not prevent a compromised monitor from sending malformed replies post-authentication.

The provided CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H) overstates certain dimensions. The attack requires the Linux host to be a Ceph client actively connected to a monitor, and the attacker must either control a Ceph monitor endpoint or achieve a network-level man-in-the-middle position on the Ceph protocol - conditions inconsistent with AC:L and PR:N in the strict CVSS sense. The I:L rating is also questionable: an uninitialized memory read does not write data and does not itself achieve integrity impact. The real risk is primarily confidentiality (kernel memory disclosure via stale buffer contents) and availability (potential misinterpretation of stale version values causing client misbehavior or crash). The 16% EPSS score is notably above the typical baseline for kernel networking flaws (~1-3%), suggesting the scoring model weighs the network vector heavily. No KEV listing and no confirmed public exploit code mean active exploitation is not confirmed. For environments running Ceph-attached Linux hosts (OpenStack, Kubernetes with Ceph CSI, Ceph RBD block storage), patching is a genuine near-term priority. For environments not using libceph/Ceph storage, exposure is nil since the vulnerable code path is only reachable when libceph is active and connected to a monitor.

An attacker controlling a rogue Ceph monitor endpoint - or positioned as a man-in-the-middle on the Ceph protocol between the Linux client and its legitimate monitor - sends a deliberately truncated MON_GET_VERSION_REPLY response. Because handle_get_version_reply() validates only that the buffer allocation is large enough (not that sufficient bytes were received), the bounds check passes and the decoder reads a second u64 from stale bytes left by a prior message in the shared buffer. The attacker can recover fragments of prior kernel network message content and, depending on what values are decoded, may cause the Ceph client to act on an invalid version number, potentially destabilizing the storage connection. No public proof-of-concept has been identified at time of analysis.