CVE-2026-52958

What it actually does

This is a Linux kernel libceph memory-safety flaw in osdmap_decode(), the routine that decodes Ceph OSD map data received from a Ceph cluster. The decoder validates that enough bytes exist for osd_state and osd_weight, but the vulnerable bounds check accounts for only one osd_weight entry instead of max_osd entries. A malformed or corrupted OSD map with an inflated max_osd value can cause the kernel Ceph client to read past the end of the received message buffer while decoding the map. The most likely technical outcome is kernel memory access beyond the intended buffer, which can trigger a kernel fault, client crash, or denial of service; depending on memory layout and kernel hardening, information exposure or more severe memory-corruption effects cannot be categorically ruled out, but no public exploit maturity is reported.

Why it matters to the business

Systems that use the Linux kernel Ceph client may be exposed to crashes or instability when processing a malicious or corrupted Ceph OSD map. In business terms, this can disrupt workloads backed by Ceph storage, including mounted CephFS volumes, RBD-backed services, and storage-dependent applications. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad opportunistic exploitation appears unlikely at this time; however, storage-layer outages can have high operational impact where Ceph is critical to application availability.

How an attack unfolds

An attacker would need a path to influence or supply Ceph OSD map data consumed by a vulnerable Linux kernel Ceph client. In a realistic scenario, this would generally require control of, compromise of, or man-in-the-middle positioning against Ceph monitor/cluster communication, or the ability to inject corrupted Ceph protocol messages into a client’s trusted storage path. The attacker crafts an OSD map where max_osd indicates more OSD entries than are actually present in the message. When the vulnerable kernel client decodes the message, the insufficient length check allows the loop to continue reading osd_weight data beyond the available buffer. This can cause an out-of-bounds kernel memory access and may lead to a kernel warning, oops, panic, client disconnect, or storage service disruption.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the libceph osdmap_decode() bounds-check fix. Because no affected product list or exact fixed package versions were provided, use the advisory from the relevant Linux distribution or kernel vendor and confirm that the patch changes the osd_weight length validation to account for max_osd * sizeof(*map->osd_weight). Prioritize kernel updates on systems that mount CephFS, use RBD via the kernel client, or otherwise connect to Ceph clusters. If immediate patching is not possible, reduce exposure by limiting Ceph client access to trusted networks, enforcing Ceph authentication and encryption where supported, restricting monitor and OSD communication paths, and monitoring for kernel faults or Ceph client disconnects. User-space Ceph clients may not be affected in the same way unless they share the vulnerable kernel code path; validate exposure based on actual kernel client usage.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not only that an updated package is installed. Reboot systems after kernel updates and verify the active kernel with standard platform tooling such as uname -a and package-manager queries. Validate exposure by checking whether the host uses the kernel Ceph client: look for CephFS mounts, RBD kernel mappings, loaded ceph/libceph/rbd kernel modules, and active connections to Ceph monitors. Confirm remediation by reviewing distribution changelogs or kernel source for the corrected ceph_decode_need() calculation in net/ceph/osdmap.c or the relevant libceph source. Operationally, monitor patched clients for absence of recurrent libceph decode errors, kernel oopses, or Ceph client disconnects after normal OSD map updates.

Typical attack path

1. Identify systems using the Linux kernel Ceph client, such as CephFS or RBD consumers.
2. Obtain a position where Ceph OSD map traffic can be controlled, spoofed, corrupted, or served from a compromised Ceph component.
3. Craft or trigger delivery of an OSD map with a max_osd value larger than the actual encoded osd_state/osd_weight content.
4. Cause the vulnerable client to receive and decode the malformed OSD map.
5. Trigger out-of-bounds memory access in libceph osdmap_decode().
6. Observe resulting client instability, kernel fault, storage disconnect, or service outage.

How to detect it

Look for evidence that Linux kernel Ceph clients received malformed OSD map data or crashed while decoding Ceph cluster maps. Relevant sources include kernel logs, system journal, dmesg output, crash dumps, kdump/vmcore artifacts, Ceph monitor logs, Ceph OSD logs, and network telemetry for Ceph monitor/OSD ports. Focus on timestamps where clients report Ceph map update failures, libceph errors, kernel oopses, panics, page faults, or call traces involving osdmap_decode, ceph_osdc, libceph, ceph.ko, or rbd. On Ceph infrastructure, review monitor logs for unusual OSD map churn, abnormal max_osd values, failed client sessions, authentication anomalies, or unexpected clients receiving maps. Because no public exploit indicators or named threat actors are reported, detection should be behavior- and artifact-based rather than signature-only. Correlate kernel crashes or client disconnects with Ceph map update events and any suspicious administrative activity or network-path changes involving Ceph monitors.

• osdmap_decode
• libceph
• ceph_decode_need
• net/ceph/osdmap.c
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• Kernel panic - not syncing
• Oops:
• Call Trace:
• ceph:
• rbd:
• ceph_osdc
• osdmap
• failed to decode
• bad osdmap
• corrupt osdmap
• malformed osdmap
• ceph.ko
• libceph.ko
• rbd.ko
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• /proc/mounts
• /sys/bus/rbd/devices

What your security team should do

• Inventory Linux systems that use kernel Ceph functionality, including CephFS mounts and RBD kernel mappings.
• Prioritize kernel patching for production systems whose availability depends on Ceph-backed storage.
• Verify that updated kernels are actually running after reboot, especially on long-lived storage and virtualization hosts.
• Restrict Ceph monitor and OSD network access to authorized clients and administrative networks only.
• Review Ceph authentication, network segmentation, and transport security controls to reduce the likelihood of malicious OSD map injection.
• Monitor kernel logs and Ceph logs for decode errors, malformed OSD map handling, client resets, kernel oopses, or panics.
• Treat any unexpected Ceph client crash following OSD map updates as potentially security-relevant until ruled out.
• Track vendor advisories for exact fixed kernel versions because fixed_versions were not provided in the input.