CVE-2026-68155

What it actually does

This flaw is a Linux kernel libceph denial-of-service issue in Ceph monitor map handling. A Ceph client can accept a CEPH_MSG_MON_MAP message that advertises zero monitors, even though a valid Ceph cluster cannot have a monitor map with no monitors. After accepting that invalid map, the kernel client may later attempt to open a monitor session and hit a BUG_ON assertion in pick_new_mon(), causing a kernel oops/panic or client crash. The practical technical effect is a crash of systems using the in-kernel Ceph client, such as CephFS or RBD clients, when they process a malformed monitor map from a monitor path.

Why it matters to the business

Successful exploitation can interrupt access to Ceph-backed storage and may crash or reboot affected Linux client systems, causing application downtime, failed I/O, degraded cluster clients, and operational disruption for workloads that depend on CephFS or RBD. Because the issue is newly published and no public exploit maturity is indicated, the highest priority is environments where untrusted, compromised, or network-adjacent systems could impersonate, intercept, or influence Ceph monitor communications.

How an attack unfolds

An attacker needs a way to cause a vulnerable Linux kernel Ceph client to receive a malformed Ceph monitor map. In realistic scenarios this could involve control of a malicious or compromised Ceph monitor, the ability to impersonate a monitor, or a network position that allows manipulation of monitor traffic depending on the deployment’s authentication and transport protections. The attacker sends or relays a CEPH_MSG_MON_MAP message where the monitor count is zero. The vulnerable libceph code treats this structurally impossible monitor map as acceptable. Later, when the client attempts to select or open a monitor session, the code reaches an assertion that assumes at least one monitor exists. That assertion fails and can crash the kernel client path, resulting in a denial of service on the affected host and interruption of Ceph-backed storage access.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the libceph fix rejecting monitor maps where num_mon equals zero. No exact fixed package versions were provided in the input, so use the appropriate distribution, appliance, cloud image, or kernel vendor advisory for the corrected kernel version. After updating, reboot systems if required so the patched kernel is running. As interim risk reduction, restrict Ceph monitor access to trusted client networks only, enforce Ceph authentication and secure transport options where available, prevent untrusted systems from reaching monitor ports, remove or quarantine suspected rogue monitor endpoints, and prioritize patching systems that mount CephFS or map RBD volumes from less trusted network segments.

How to confirm the fix worked

Confirm that each exposed host is running a kernel build that includes the libceph change in ceph_monmap_decode() to reject monmaps with num_mon == 0. Validate the running kernel version after reboot rather than only checking installed packages. Review distribution advisories or kernel changelogs for language such as rejecting zero-monitor monmaps in libceph. From an exposure perspective, inventory systems with loaded Ceph kernel modules or active Ceph mounts, including ceph, libceph, rbd, and CephFS usage. In a controlled test environment only, validation can include sending a malformed zero-monitor monmap and confirming the client rejects it without a kernel oops or panic; do not perform this test on production systems because it may crash vulnerable clients.

Typical attack path

1. Identify Linux systems using the in-kernel Ceph client for CephFS, RBD, or other libceph-backed storage access.
2. Gain the ability to deliver monitor-map data to the client, such as through a compromised Ceph monitor, rogue monitor endpoint, or network interception position.
3. Send a CEPH_MSG_MON_MAP message containing a monmap with num_mon set to zero.
4. Allow the client to accept the invalid monmap and continue normal monitor-session handling.
5. Trigger or wait for the client to open or re-open a monitor session.
6. The client hits the kernel BUG_ON assertion in pick_new_mon(), causing a kernel crash, oops, panic, or service interruption.

How to detect it

To determine whether this was already exploited, focus on evidence of unexpected kernel crashes or oops events on systems using the Linux kernel Ceph client. Relevant log sources include systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent kernel crash logs, kdump/vmcore data, Ceph client logs, Ceph monitor logs, and network telemetry for Ceph monitor traffic. Look for kernel stack traces referencing libceph monitor-client functions such as pick_new_mon() or __open_session(), especially shortly after Ceph monitor map updates, monitor reconnects, or session-opening activity. Investigate client crashes that coincide with connections to unusual Ceph monitor addresses, monitor membership changes, or monitor-map messages that cannot be reconciled with the legitimate cluster configuration. If packet captures are available, inspect Ceph monitor traffic for CEPH_MSG_MON_MAP messages where the decoded monitor count is zero. Because the vulnerable code may crash before producing a clear application-level error, absence of a specific log string does not rule out exploitation; correlate reboots, kernel panic timestamps, Ceph reconnect activity, and monitor endpoint changes.

• pick_new_mon
• __open_session
• libceph
• mon_client.c
• net/ceph/mon_client.c
• kernel BUG
• BUG: unable to handle kernel
• Oops:
• Kernel panic
• CEPH_MSG_MON_MAP
• monmap
• num_mon == 0
• num_mon=0
• ceph_monmap_decode

What your security team should do

• Inventory Linux hosts that use the in-kernel Ceph client, including CephFS mounts and RBD mappings, and prioritize those with access to Ceph monitor networks.
• Track vendor kernel advisories and apply the first fixed kernel release available for each affected distribution or platform; reboot into the patched kernel where required.
• Restrict Ceph monitor network exposure with firewall rules, security groups, segmentation, and allowlists so only trusted clients and monitors can communicate.
• Verify Ceph monitor endpoint integrity and investigate any unexpected monitor addresses, configuration changes, or client connections to nonstandard monitor hosts.
• Ensure Ceph authentication is enforced and avoid unauthenticated or weakly protected monitor communication paths.
• Add monitoring for kernel oops/panic events involving libceph, mon_client.c, pick_new_mon, or __open_session, especially following Ceph monitor reconnects or map updates.
• Preserve logs from affected hosts and Ceph monitors after unexplained client crashes so exploitation can be distinguished from ordinary kernel or storage failures.