CVE-2026-52954

What it actually does

This flaw is a denial-of-service condition in the Linux kernel Ceph client library, libceph. When the kernel receives a CEPH_MSG_OSD_MAP message, it decodes the embedded CRUSH map and any choose_args entries. A malformed or malicious map can contain two choose_args entries with the same choose_args_index. The vulnerable code attempts to insert both into an rbtree keyed by that index and hits a kernel assertion on the duplicate insertion, triggering a kernel BUG and likely causing a kernel panic or system crash. The issue is not known to provide code execution or data disclosure; the primary impact is availability loss on systems using the in-kernel Ceph client, such as CephFS or RBD kernel mounts.

Why it matters to the business

Systems that rely on the Linux kernel Ceph client can be forced to crash if they process a malicious or corrupted Ceph OSD map, disrupting applications, storage access, and any workloads running on the affected host. The risk is highest where hosts connect to untrusted, compromised, or weakly authenticated Ceph clusters. The EPSS score is low and this vulnerability is not listed in CISA KEV or known ransomware use, so broad exploitation is not currently indicated, but storage-client crashes can still cause meaningful operational outages.

How an attack unfolds

An attacker must cause an affected Linux kernel Ceph client to receive and decode a crafted CEPH_MSG_OSD_MAP message. In practical terms, this usually requires control of, compromise of, or successful impersonation of a Ceph monitor or another trusted part of the Ceph control plane that distributes OSD maps to clients. The attacker crafts an OSD map containing a CRUSH map with duplicate choose_args_index values. When the vulnerable kernel client decodes the map, the first entry is inserted into the CRUSH map choose_args rbtree, and the duplicate insertion triggers an assertion in the rbtree insertion path. The kernel then raises a BUG condition, which can panic or crash the host, causing loss of access to Ceph-backed storage and interruption of dependent workloads.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the libceph fix for rejecting duplicate choose_args entries instead of asserting. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution and kernel stream to identify the corrected kernel build. Reboot into the fixed kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running. As interim mitigations, restrict Ceph client connectivity to trusted monitors only, enforce Ceph authentication and message integrity protections where available, block untrusted access to Ceph monitor and OSD networks, avoid mounting untrusted Ceph clusters with the kernel client, and consider isolating or disabling CephFS/RBD kernel mounts on systems that cannot be patched promptly.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, contains the fix by checking the active kernel version with uname -r and comparing it against the distribution vendor advisory or changelog for this vulnerability. Validate that hosts using CephFS or RBD kernel clients have been rebooted into the patched kernel. Review whether Ceph client systems can communicate only with expected Ceph monitor addresses and that untrusted networks cannot reach the Ceph control plane. Where feasible in a non-production test environment, confirm that malformed OSD maps with duplicate choose_args entries are rejected gracefully rather than causing a kernel BUG. Also verify that crash dumps and kernel logs no longer show stack traces involving decode_choose_args or insert_choose_arg_map during Ceph map processing.

Typical attack path

1. Identify Linux systems using the in-kernel Ceph client, such as CephFS mounts, RBD kernel mappings, or other libceph-backed storage access.
2. Gain the ability to send trusted Ceph OSD map updates to those clients, typically by compromising or impersonating a Ceph monitor/control-plane component or by targeting clients connected to an untrusted cluster.
3. Construct a CEPH_MSG_OSD_MAP message whose embedded CRUSH map contains duplicate choose_args_index values in the choose_args section.
4. Deliver the malformed OSD map to an affected kernel client during normal Ceph map update processing.
5. The client decodes the message, attempts duplicate rbtree insertion, triggers a kernel BUG, and crashes or becomes unavailable.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, crash dumps, and hypervisor or host availability events for sudden panics on systems using CephFS or RBD kernel clients. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, pstore, console logs, and Ceph client logs if present. Look for kernel BUG or panic messages with stack traces referencing libceph, CRUSH map decoding, decode_choose_args, insert_choose_arg_map, decode_crush, or OSD map processing. Correlate crashes with Ceph monitor activity, OSD map epoch changes, cluster membership changes, or suspicious access to Ceph monitor ports from unexpected systems. Because malformed CEPH_MSG_OSD_MAP contents are not normally preserved in standard logs, absence of a packet capture or crash dump may make definitive attribution difficult; repeated Ceph-related kernel BUG events across clients connected to the same cluster should be treated as suspicious.

• insert_choose_arg_map
• decode_choose_args
• decode_crush
• CEPH_MSG_OSD_MAP
• libceph
• kernel BUG
• Kernel panic - not syncing
• RIP: insert_choose_arg_map
• RIP: decode_choose_args
• Call Trace: decode_choose_args
• Call Trace: insert_choose_arg_map
• Call Trace: decode_crush
• /var/crash
• /sys/fs/pstore
• /proc/vmcore

What your security team should do

• Inventory Linux hosts using the in-kernel Ceph client, including CephFS mounts and RBD kernel mappings, and prioritize them for kernel updates.
• Patch and reboot affected systems into a fixed kernel from the appropriate OS or kernel vendor.
• Treat Ceph monitor and OSD networks as trusted infrastructure; restrict access with network segmentation, firewall rules, and strong Ceph authentication.
• Review Ceph cluster trust boundaries and avoid connecting production hosts to untrusted or externally managed Ceph clusters with the kernel client.
• Monitor kernel logs, crash dumps, and availability telemetry for Ceph-related kernel BUG or panic events.
• Because this is not currently in CISA KEV, not known for ransomware use, and has low EPSS, prioritize based on exposure and storage criticality rather than assuming active mass exploitation.