CVE-2026-68154

What it actually does

This vulnerability is an improper input validation flaw in the Linux kernel Ceph client code, specifically in libceph CRUSH map decoding. CRUSH bucket type 0 is reserved for leaf devices, but a malformed CRUSH map could define a bucket using type 0. If accepted, the CRUSH mapper may treat a negative bucket identifier as a device identifier and pass it into OSD weight handling, causing a negative index access into the OSD weight array. The most likely technical impact is kernel memory access outside expected bounds, which can lead to kernel crashes, denial of service, or potentially undefined kernel behavior when a system processes a malicious or corrupted Ceph CRUSH map.

Why it matters to the business

Systems that use the Linux kernel Ceph client to connect to Ceph storage may be vulnerable to disruption if they process a malicious or malformed CRUSH map. The primary business risk is loss of availability for workloads depending on Ceph-backed storage, including service outages, application instability, failed mounts, or node crashes. Because this issue was recently published and is not listed in CISA KEV, there is no confirmed broad exploitation signal from the provided data, but storage-layer denial of service can still have high operational impact in environments that rely on Ceph for critical data access.

How an attack unfolds

An attacker would need a way to cause a vulnerable Linux Ceph client to receive and decode a malformed CRUSH map. This is most plausible where an attacker can control, compromise, impersonate, or tamper with Ceph monitor responses, or otherwise introduce a malicious CRUSH map into the client’s trust path. The crafted CRUSH map defines an invalid bucket with type 0, violating the kernel mapper’s assumption that type 0 only represents leaf devices. When the client decodes and later uses this map for placement decisions, the mapper can misinterpret a negative bucket ID as a device ID and perform an invalid access into the OSD weight array. Successful exploitation would likely manifest as a kernel fault, client instability, or denial of service on systems using the affected Ceph client path.

How to fix it

Upgrade affected Linux kernels to versions that include the libceph fix rejecting CRUSH buckets with type 0 during CRUSH map decoding. Because no product-specific fixed versions were provided, use vendor advisories for the relevant Linux distribution or kernel source branch to identify the patched kernel release containing the fix for this issue. Where immediate patching is not possible, reduce exposure by restricting Ceph monitor access to trusted networks, enforcing strong Ceph authentication, preventing untrusted administrative access to Ceph configuration and maps, and avoiding use of untrusted or externally supplied CRUSH maps. Reboot systems as required after kernel updates so the patched kernel is actually running.

How to confirm the fix worked

Confirm remediation by verifying that systems using the kernel Ceph client are running a vendor kernel version that includes the libceph CRUSH map validation fix. Validate exposure by inventorying hosts with Ceph kernel mounts or Ceph client modules loaded, such as systems using ceph.ko/libceph.ko. Review distribution security advisories, kernel changelogs, or package metadata for the fix that rejects zero bucket types in crush_decode. After patching and rebooting, confirm the active kernel version matches the patched package, and test Ceph mount and I/O functionality against legitimate CRUSH maps to ensure normal operation remains unaffected.

Typical attack path

1. Identify Linux systems using the kernel Ceph client or Ceph-backed mounts.
2. Gain the ability to influence the CRUSH map delivered to clients, such as by compromising Ceph monitor infrastructure, abusing administrative access, or positioning to tamper with trusted Ceph traffic.
3. Create a malformed CRUSH map containing a bucket with reserved type 0.
4. Cause a vulnerable client to decode and use the malformed CRUSH map.
5. Trigger CRUSH placement logic so the invalid bucket/device interpretation reaches OSD weight handling.
6. Cause kernel instability, crash, or denial of service on the affected client.

How to detect it

Look for evidence that Ceph clients processed malformed CRUSH maps followed by kernel faults or service disruption. Relevant log sources include kernel logs, system journal entries, dmesg output, Ceph client logs, Ceph monitor audit logs, and change records for CRUSH map updates. Investigate any kernel OOPS, BUG, panic, general protection fault, or page fault events that occur shortly after Ceph monitor communication, CRUSH map updates, Ceph mount activity, or OSD map changes. On Ceph infrastructure, review administrative actions that modified or imported CRUSH maps and verify they came from expected operators and hosts. Since no public exploit artifacts or actor-specific indicators were provided, detection should focus on behavioral evidence: suspicious CRUSH map changes, unexpected client crashes, repeated Ceph reconnects, and kernel faults involving libceph, crush_decode, CRUSH mapping, or Ceph client modules.

• crush_decode
• libceph
• ceph.ko
• libceph.ko
• CRUSH map
• crush map
• kernel BUG
• kernel panic
• general protection fault
• unable to handle kernel paging request
• Oops:
• ceph:
• mounted filesystem with ordered data mode
• /sys/module/ceph
• /sys/module/libceph

What your security team should do

• Prioritize patching Linux systems that mount or consume Ceph storage using the kernel Ceph client, especially production nodes with critical storage dependencies.
• Inventory Ceph client usage across fleets by checking mounted filesystems, loaded kernel modules, and configuration management records.
• Restrict Ceph monitor and cluster management interfaces to trusted administrative networks only.
• Review Ceph administrative access controls to ensure only authorized operators can modify or inject CRUSH maps.
• Monitor recently updated or unstable Ceph client nodes for kernel crashes, OOPS events, or unexpected remounts following CRUSH map changes.
• If patching must be delayed, limit client exposure to trusted Ceph clusters and avoid connecting vulnerable clients to clusters or monitors outside organizational control.
• Track Linux distribution advisories for exact fixed kernel package versions and ensure systems are rebooted into the patched kernel.