CVE-2026-68153

What it actually does

This is a Linux kernel use-after-free in the Ceph client library debugfs handling. During Ceph client teardown, the monitor client can be stopped and its monmap structure freed while a concurrent read of the per-client debugfs monmap file is still executing. That race can cause the kernel to dereference freed memory in the debugfs callback path, potentially leading to a kernel crash, memory corruption, or, depending on kernel configuration and exploitability conditions, possible local privilege escalation. The resolved behavior removes the debugfs files before stopping the OSD and monitor clients so active debugfs handlers are drained and new reads are blocked before teardown continues.

Why it matters to the business

Systems using Ceph-related Linux kernel functionality, such as CephFS or RBD clients, may be exposed if local users or processes can access Ceph debugfs entries while Ceph clients are being removed or shut down. The most likely operational impact is host instability or denial of service through a kernel crash, which can disrupt storage clients and workloads depending on them. There is no current KEV listing, no known ransomware association, and no public exploit maturity reported, but the issue is newly published and should still be prioritized on Linux systems that use kernel Ceph clients or expose debugfs locally.

How an attack unfolds

An attacker first needs local access to a Linux system where the kernel Ceph client is active and Ceph debugfs entries are available. The attacker then repeatedly reads the Ceph monmap debugfs file while causing or waiting for Ceph client teardown, such as unmounting CephFS, detaching an RBD device, stopping a workload that uses libceph, or otherwise triggering cleanup of the Ceph client. If the timing aligns, the debugfs read enters the monmap display callback after the monitor client's monmap memory has already been freed. The resulting use-after-free can corrupt kernel execution state or trigger a kernel fault. In practical terms, exploitation is race-dependent and most directly useful for causing a local denial of service; privilege escalation would require additional exploit development and favorable kernel memory-layout conditions.

How to fix it

Apply a vendor kernel update that includes the libceph fix to remove Ceph per-client debugfs files before stopping the OSD and monitor clients. Because no exact affected product list or fixed package versions were provided, use the applicable Linux distribution or kernel vendor advisory as the source of truth for fixed kernel builds. Reboot into the updated kernel after installation; merely installing the package is not sufficient for kernel vulnerabilities. As mitigations until patching is complete, unmount debugfs where it is not operationally required, restrict access to /sys/kernel/debug to trusted administrators only, disable or avoid loading Ceph kernel client modules on systems that do not need them, and limit local shell or container access on Ceph client hosts.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, is a vendor-fixed build containing the libceph debugfs teardown patch. Validate with uname, package manager metadata, vendor security advisories, or source-level confirmation that ceph_destroy_client() removes debugfs files before stopping the OSD and monitor clients. Check whether debugfs is mounted at /sys/kernel/debug and whether Ceph entries exist under /sys/kernel/debug/ceph. On patched systems, regression testing should show that repeated reads of Ceph monmap debugfs files during CephFS unmount, RBD detach, or Ceph client shutdown do not produce kernel warnings, KASAN reports, Oops messages, or host instability.

Typical attack path

1. Gain local code execution or an interactive local account on a Linux system using the kernel Ceph client.
2. Confirm that debugfs is mounted and Ceph client debugfs entries are present under the kernel debug filesystem.
3. Continuously read the Ceph monmap debugfs file while Ceph client teardown is triggered or occurs naturally.
4. Win the race between debugfs file access and Ceph monitor client cleanup.
5. Cause a kernel use-after-free, resulting in a crash, memory corruption, or potentially further exploitation if the platform is susceptible.

How to detect it

Look for evidence of kernel faults or memory-safety detections around Ceph client teardown. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, vmcore analysis, audit logs for debugfs access, and endpoint telemetry that records file reads under /sys/kernel/debug. Search for KASAN use-after-free reports, kernel Oops or panic messages, and call traces containing monmap_show, ceph_monc_stop, ceph_destroy_client, ceph_debugfs, or libceph. Correlate these events with CephFS unmounts, RBD detach operations, service shutdowns, module unloads, or repeated reads of /sys/kernel/debug/ceph/*/monmap. Because exploitation is race-based and may leave only crash artifacts, absence of a clear IOC does not prove non-exploitation; unexplained kernel crashes on Ceph client hosts should be treated as suspicious until logs and crash dumps are reviewed.

• /sys/kernel/debug/ceph/
• /sys/kernel/debug/ceph/*/monmap
• monmap_show
• ceph_monc_stop
• ceph_destroy_client
• libceph
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• RIP: 0010:monmap_show
• RIP: 0010:ceph_monc_stop
• RIP: 0010:ceph_destroy_client
• debugfs_remove
• ceph_debugfs

What your security team should do

• Inventory Linux systems using kernel Ceph clients, including CephFS mounts and RBD devices, and prioritize them for kernel updates.
• Patch and reboot Ceph client hosts to a vendor-fixed kernel as soon as practical, prioritizing multi-user systems and systems where untrusted local code can run.
• Temporarily unmount or restrict debugfs on systems where it is not required for operations or troubleshooting.
• Review access controls for local users, privileged containers, and workloads that may be able to read /sys/kernel/debug/ceph entries.
• Monitor kernel logs for use-after-free, KASAN, Oops, panic, or call traces involving libceph, monmap_show, ceph_monc_stop, or ceph_destroy_client.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, and workload timing information around Ceph unmounts, RBD detachments, or service shutdowns.