CVE-2026-52955

What it actually does

This flaw is an out-of-bounds memory access in the Linux kernel libceph CRUSH map decoder. A malformed Ceph OSD map can contain inconsistent bucket algorithm fields: one value is used to size and allocate the bucket structure, while a second value is later trusted when processing or destroying it. If those values differ, kernel code may read, write, or free memory using the wrong bucket layout. The most likely impact is a kernel crash or denial of service on systems using the kernel Ceph client, with possible kernel memory corruption depending on platform, configuration, and exploit reliability.

Why it matters to the business

Systems that mount or otherwise use Ceph through the Linux kernel client could be crashed by a malicious or compromised Ceph control-plane source that delivers a malformed OSD map. In production storage environments, this can interrupt access to CephFS, RBD-backed workloads, or other services depending on Ceph storage. The issue is not currently listed in CISA KEV, is not flagged as ransomware-used, has low EPSS activity, and has no public exploit maturity reported, so it should be prioritized as important for exposed Ceph environments rather than as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs a way to deliver a crafted CEPH_MSG_OSD_MAP message to a vulnerable Linux kernel Ceph client. The most plausible paths are compromise of a Ceph monitor or other trusted Ceph infrastructure, control of a rogue/malicious Ceph cluster that a victim client connects to, or network-positioned manipulation where Ceph authentication and transport protections are absent or misconfigured. The attacker crafts a CRUSH map containing at least one bucket where the outer algorithm field and the bucket's internal algorithm field disagree. When the vulnerable kernel client decodes the OSD map, it allocates memory based on the first algorithm value but later processes or frees the bucket according to the second value. This mismatch can trigger out-of-bounds memory access in kernel context, leading to a crash and potentially exploitable memory corruption.

How to fix it

Apply Linux kernel updates from the operating system or appliance vendor that include the libceph fix for CRUSH map bucket algorithm validation. Where exact fixed package versions are not available from the advisory input, track the relevant distribution kernel security advisories and update all systems using kernel Ceph functionality. Reboot into the patched kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running. As interim risk reduction, restrict Ceph client connectivity to trusted monitor networks, enforce Ceph authentication and secure transport where available, prevent clients from connecting to untrusted Ceph clusters, and remove or disable unused CephFS/RBD/kernel Ceph client usage on systems that do not require it.

How to confirm the fix worked

Confirm that affected hosts are running a vendor kernel build that contains the libceph CRUSH decoder fix, not only that an updated package is installed. Validate with the running kernel version, distribution security advisory status, and package changelog references to the libceph/crush_decode fix. Inventory systems for active Ceph kernel client use by checking mounted CephFS filesystems, mapped RBD devices, loaded Ceph-related kernel modules, and active network connections to Ceph monitors. If feasible in a non-production test environment, verify that malformed CRUSH maps are rejected without kernel warnings, crashes, KASAN reports, or Oops messages.

Typical attack path

1. Identify systems using the Linux kernel Ceph client, such as CephFS mounts, RBD clients, or hosts with active libceph communication.
2. Gain the ability to influence or impersonate a Ceph OSD map source, most realistically by compromising Ceph monitor infrastructure, operating a malicious Ceph cluster, or exploiting weak Ceph transport/authentication controls.
3. Construct a CEPH_MSG_OSD_MAP containing a CRUSH map with at least one bucket whose two algorithm fields do not match.
4. Deliver the malformed OSD map to the vulnerable client during normal Ceph map synchronization or cluster connection handling.
5. Trigger libceph crush_decode() processing in kernel context.
6. Cause out-of-bounds access during bucket processing or destruction, resulting in kernel instability, denial of service, or possible memory corruption.

How to detect it

Look for evidence of kernel crashes, memory corruption reports, or Ceph client failures occurring during OSD map or CRUSH map processing. Primary log sources include kernel logs, system journal entries, crash dump infrastructure, kdump/vmcore analysis, Ceph client logs, Ceph monitor logs, and network telemetry showing unusual or unexpected Ceph monitor connections. Search for kernel Oops, panic, KASAN, slab out-of-bounds, or general protection fault messages near libceph, crush_decode(), crush_destroy_bucket(), CRUSH map parsing, or CEPH_MSG_OSD_MAP handling. On Ceph infrastructure, review monitor logs for unusual OSD map propagation, unexpected monitor leadership or membership changes, client connections from unfamiliar sources, or suspicious map updates around the time of client crashes. Network detection is difficult without deep protocol inspection, but unexpected Ceph monitor traffic to untrusted endpoints should be treated as suspicious. Absence of these artifacts does not prove non-exploitation because a successful denial-of-service event may leave only generic kernel crash evidence.

• crush_decode
• crush_destroy_bucket
• CEPH_MSG_OSD_MAP
• OSD map
• crush map
• libceph
• ceph:
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• RIP: crush_decode
• RIP: crush_destroy_bucket

What your security team should do

• Prioritize patching Linux systems that actively use CephFS, RBD, or other kernel Ceph client functionality, especially storage nodes, virtualization hosts, Kubernetes nodes, and application servers dependent on Ceph-backed storage.
• Reboot patched systems and verify the running kernel includes the vendor fix.
• Audit Ceph client exposure and ensure clients only connect to trusted Ceph monitor endpoints.
• Review Ceph authentication and transport security settings to reduce the chance of rogue or tampered OSD map delivery.
• Monitor kernel logs for crashes or memory-safety warnings involving libceph, crush_decode, CRUSH map parsing, or OSD map processing.
• Investigate any unexplained kernel panics or Ceph client resets on storage-dependent hosts since publication, particularly if preceded by OSD map changes or monitor connectivity anomalies.
• Because EPSS is low and there is no KEV listing or known public exploit maturity, schedule remediation according to normal kernel/storage maintenance windows unless the environment connects clients to untrusted or multi-tenant Ceph clusters.