CVE-2026-68159

What it actually does

This flaw is a stack-based out-of-bounds write in the Linux kernel Ceph client code, specifically in libceph OSDMap decoding. A Ceph monitor can provide a user-controlled pg_temp, pg_upmap, or pg_upmap_items entry whose decoded length exceeds the fixed CEPH_PG_MAX_SIZE limit of 32. The kernel decodes and stores the oversized list, and later code copies it into a fixed-size on-stack array, corrupting adjacent stack memory. The most likely technical outcomes are kernel crash, BUG/OOPS, or denial of service on systems using kernel Ceph/RBD/CephFS functionality. Depending on kernel build, memory layout, hardening, and attacker control over copied values, more severe kernel memory corruption outcomes may be possible, but exploitation requires the victim kernel client to accept a malicious or compromised Ceph monitor/OSDMap source.

Why it matters to the business

Organizations using Linux kernel Ceph clients, including RBD block devices or CephFS mounts, may experience host instability, storage outages, or application downtime if a malicious or compromised Ceph monitor sends a crafted OSDMap. The issue is not currently listed in CISA KEV and no public exploit maturity is indicated, but it was published recently, so exposed Ceph environments should treat it as a priority kernel/client update because storage-plane failures can cascade into service interruptions.

How an attack unfolds

An attacker first needs a position where they can influence the Ceph monitor data consumed by a Linux kernel Ceph client. This could occur if a Ceph monitor is compromised, a rogue monitor is trusted by the client, or a client is induced to connect to attacker-controlled Ceph infrastructure. The attacker then crafts an OSDMap containing pg_temp, pg_upmap, or pg_upmap_items entries with more than 32 OSD entries for a placement group. Vulnerable kernel libceph code decodes the oversized entry without enforcing CEPH_PG_MAX_SIZE. When the client later resolves acting/up OSDs for an I/O operation, RBD image probe, CephFS activity, or other Ceph operation, the decoded list is copied into a fixed-size stack array. This causes a stack out-of-bounds write in kernel context, typically resulting in a kernel BUG, OOPS, panic, or host denial of service.

How to fix it

Update the Linux kernel to a version containing the libceph fix that rejects pg_temp, pg_upmap, and pg_upmap_items entries longer than CEPH_PG_MAX_SIZE during OSDMap decoding. Because fixed package versions were not provided, obtain vendor-specific patched kernel builds from the relevant Linux distribution or appliance vendor and prioritize systems that mount CephFS, use kernel RBD, or otherwise load the in-kernel Ceph client modules. If immediate patching is not possible, reduce exposure by ensuring Ceph clients only connect to trusted monitor endpoints, restricting Ceph monitor network access, enforcing Ceph authentication, removing untrusted monitor addresses from client configuration, and disabling or unmounting kernel Ceph/RBD usage where feasible until patched.

How to confirm the fix worked

Confirm remediation by verifying that running kernels on Ceph client hosts include the vendor patch for this issue, not merely that packages are installed on disk. Reboot into the patched kernel where required. Validate exposure by identifying hosts with loaded or configured kernel Ceph components, such as ceph, libceph, rbd, or cephfs modules, active CephFS mounts, mapped RBD devices, or ceph.conf monitor configuration. In test environments only, confirm that malformed OSDMap entries exceeding CEPH_PG_MAX_SIZE are rejected rather than processed; do not perform destructive testing against production clusters.

Typical attack path

1. Gain control of, compromise, or impersonate a Ceph monitor trusted by a Linux kernel Ceph client.
2. Create or deliver a malicious OSDMap containing an oversized pg_temp, pg_upmap, or pg_upmap_items list for a placement group.
3. Wait for or trigger the victim kernel client to process the OSDMap during CephFS, RBD, or librados-backed kernel client activity.
4. Cause the vulnerable decode and later copy path to write more than CEPH_PG_MAX_SIZE entries into the fixed-size on-stack ceph_osds.osds array.
5. Crash or destabilize the victim host kernel, potentially interrupting workloads dependent on Ceph-backed storage.

How to detect it

Look for evidence that Linux Ceph client hosts processed malformed OSDMap data and crashed or reported kernel memory corruption. Primary log sources include kernel ring buffer output, system journal, syslog, crash dumps, kdump/vmcore artifacts, hypervisor reset logs, and Ceph client/monitor logs. Search for kernel stack traces referencing libceph OSDMap handling, especially ceph_pg_to_up_acting_osds, calc_target, __submit_request, ceph_osdc_start_request, ceph_osdc_call, rbd_dev_image_probe, and do_rbd_add. Also review Ceph monitor logs and administrative audit history for unexpected OSDMap changes, pg_temp/pg_upmap modifications, monitor membership changes, suspicious monitor restarts, or unknown monitor endpoints. Because exploitation depends on malicious OSDMap delivery, correlate host crashes with recent Ceph monitor map/OSDMap updates and client reconnections. Absence of these strings does not prove absence of exploitation, particularly if kernel logs were lost during a panic.

• KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds
• kernel BUG at net/ceph/osdmap.c:2670
• ceph_pg_to_up_acting_osds
• net/ceph/osdmap.c:2617
• net/ceph/osdmap.c:2833
• calc_target (net/ceph/osd_client.c:1638)
• __submit_request (net/ceph/osd_client.c:2394)
• ceph_osdc_start_request (net/ceph/osd_client.c:2490)
• ceph_osdc_call (net/ceph/osd_client.c:5164)
• rbd_dev_image_probe (drivers/block/rbd.c:6899)
• do_rbd_add (drivers/block/rbd.c:7138)
• BUG: KASAN: stack-out-of-bounds
• Write of size 4
• pg_temp
• pg_upmap
• pg_upmap_items

What your security team should do

• Inventory Linux systems using kernel Ceph clients, including CephFS mounts and RBD mappings, and rank them by business criticality.
• Apply vendor kernel updates containing the libceph OSDMap length validation fix, then reboot affected hosts into the patched kernel.
• Restrict Ceph monitor access to authorized client and cluster networks only; block monitor ports from untrusted networks.
• Review Ceph monitor integrity and configuration for unexpected monitor endpoints, recently changed monitor maps, or signs of compromise.
• Harden Ceph authentication and ensure clients do not trust rogue or test monitor endpoints.
• Monitor kernel logs for ceph_pg_to_up_acting_osds, stack-out-of-bounds, KASAN, kernel BUG, OOPS, or panic events on Ceph client hosts.
• Prepare operational recovery plans for storage-client host crashes, especially where RBD or CephFS supports critical services.