CVE-2026-68157

What it actually does

This is a Linux kernel denial-of-service flaw in libceph, the kernel client library used by Ceph-backed filesystems and block devices. When localized read selection processes a malformed Ceph CRUSH map, it can encounter a parent bucket whose bucket name exists but whose type name metadata is missing. The vulnerable path dereferences a NULL type-name pointer and passes it into strcmp(), triggering a kernel NULL pointer dereference. Depending on kernel configuration and workload, this can crash the calling kernel context, produce an oops, disrupt Ceph-backed storage access, or panic/reboot the host.

Why it matters to the business

Systems that mount or consume Ceph storage through the Linux kernel client may become unstable or unavailable if they receive malformed CRUSH hierarchy data. The main operational risk is interruption of storage-backed services, application downtime, failed reads, node crashes, or cluster workload disruption. Exploitation generally requires the attacker to influence the Ceph cluster map or operate a malicious/compromised Ceph environment, so exposure is highest for hosts connected to untrusted, shared, or compromised Ceph clusters. The issue is recently published, not listed in CISA KEV, and has no reported exploit maturity in the provided data, but storage-plane crashes can still have high operational impact.

How an attack unfolds

An attacker first needs a path to supply or influence Ceph CRUSH map data consumed by a vulnerable Linux kernel Ceph client. In a realistic scenario, this means compromising Ceph monitor/control-plane authority, abusing administrative access to the Ceph cluster, or convincing a vulnerable client to connect to a malicious Ceph environment. The attacker introduces malformed hierarchy metadata where a parent bucket has a valid name but its type lacks a corresponding entry in the type_names metadata. When the Linux client performs localized read selection, it walks the CRUSH hierarchy, calls get_immediate_parent(), and reaches the malformed bucket. The vulnerable code does not adequately verify that both the bucket name and type name are present, causing a NULL pointer to be used in strcmp(). The result is a kernel oops or panic, leading to denial of service for the affected host and interruption of Ceph-backed storage operations.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the libceph fix for guarded CRUSH type-name lookup. Because no exact fixed package versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the first patched kernel for each deployed platform. After patching, reboot hosts as required so the fixed kernel is running. As temporary mitigations, avoid connecting production hosts to untrusted Ceph clusters, restrict Ceph administrative access, validate CRUSH map changes through change control, and investigate any unexpected or malformed CRUSH map updates. If feasible, disable or avoid workloads that rely on kernel Ceph localized read behavior until patched, but do not treat configuration changes as a substitute for the kernel fix.

How to confirm the fix worked

Confirm that each host using CephFS, RBD, or other kernel Ceph integrations is running a kernel build that includes the libceph patch. Validate with distribution package metadata, kernel changelogs, or vendor advisories rather than relying only on the upstream version string. Rebooted systems should show the patched kernel in uname -a and package manager output. Review Ceph client usage by checking mounted Ceph filesystems, mapped RBD devices, kernel modules, and service dependencies. Where safe, test normal Ceph read operations after patching and confirm no new kernel oops, NULL pointer dereference, or libceph warnings appear in kernel logs.

Typical attack path

1. Gain the ability to control, modify, or impersonate Ceph CRUSH map data consumed by a vulnerable Linux kernel client.
2. Craft or deploy a malformed CRUSH hierarchy where a parent bucket name exists but its type name metadata is missing.
3. Cause a vulnerable client to perform localized read selection against the affected Ceph map.
4. Trigger get_immediate_parent() in libceph while it evaluates the malformed parent bucket.
5. Cause a NULL pointer dereference during strcmp(), producing a kernel oops, storage disruption, or host crash.

How to detect it

To determine whether exploitation or triggering has already occurred, review kernel logs, system journals, crash dumps, and Ceph client/monitor logs around periods of storage disruption or host reboot. Relevant sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, systemd journal entries, kdump/vmcore artifacts, Ceph monitor logs, Ceph manager logs, and audit logs covering Ceph administrative commands or CRUSH map changes. Look for kernel oops or panic events involving libceph, get_immediate_parent(), CRUSH map processing, strcmp(), or NULL pointer dereference. Correlate crashes with recent CRUSH map updates, osd crush rule changes, ceph osd setcrushmap activity, unusual ceph osd crush commands, or unexpected monitor quorum/control-plane access. Because successful exploitation may leave only a kernel crash artifact rather than a network signature, absence of explicit exploit strings does not rule out triggering; focus on crash timing, storage errors, and suspicious Ceph map modifications.

• BUG: kernel NULL pointer dereference
• NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• get_immediate_parent
• libceph
• strcmp
• CRUSH map
• type_names
• ceph osd setcrushmap
• ceph osd crush
• osd crush rule
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux hosts that use Ceph through the kernel client, including CephFS mounts and RBD-backed workloads.
• Prioritize patching storage-critical hosts, hypervisors, Kubernetes nodes, and application servers that depend on Ceph-backed storage.
• Restrict Ceph monitor and administrative access to trusted management networks and authorized operators only.
• Review recent CRUSH map changes, Ceph control-plane access, and administrative actions for unauthorized or unexpected modifications.
• Add monitoring for kernel oops/panic events mentioning libceph, CRUSH, get_immediate_parent(), strcmp(), or NULL pointer dereference.
• If any crash indicators are found, preserve kernel logs, vmcore dumps, Ceph monitor logs, and recent CRUSH maps for forensic review.
• Track Linux distribution advisories for exact fixed kernel package versions and ensure hosts are rebooted into the patched kernel.