CVE-2026-52956

What it actually does

This flaw is an out-of-bounds memory access in the Linux kernel Ceph client authentication/decryption path, specifically libceph's __ceph_x_decrypt() handling of cephx encrypted authentication data. A crafted Ceph protocol message can cause the kernel to interpret an undersized ciphertext buffer as a ceph_x_encrypt_header and read the header magic field before confirming that enough bytes are present. The most likely technical effect is a kernel fault, warning, or panic leading to denial of service for systems using the in-kernel Ceph client; impact may vary based on kernel hardening, memory layout, and how the malformed frame is processed.

Why it matters to the business

Systems that mount or communicate with Ceph storage using the affected Linux kernel client may be vulnerable to service disruption if they receive a malformed or malicious Ceph authentication response. This can affect workloads that depend on Ceph-backed storage, including file systems, block devices, container platforms, virtualization stacks, and storage nodes. The issue is not currently listed in CISA KEV, has no reported mature exploitation, and has a low EPSS score, but it is still operationally important for organizations that use Ceph because kernel-level faults can cause node instability or outages.

How an attack unfolds

An attacker must be in a position to send crafted Ceph protocol traffic to a vulnerable Linux kernel Ceph client. This could include control of a malicious Ceph service endpoint, compromise of a Ceph monitor or related service participating in authentication, or a network position that allows manipulation of Ceph authentication traffic. During cephx authentication, the attacker sends a FRAME_TAG_AUTH_REPLY_MORE-style message or similar malformed frame where the ciphertext length is shorter than the ceph_x_encrypt_header expected by __ceph_x_decrypt(). The vulnerable kernel code attempts to read hdr->magic from the undersized buffer, causing an out-of-bounds access. Depending on kernel configuration and runtime conditions, this may result in authentication failure, kernel warning, crash, or denial of service.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the libceph fix for CVE-2026-52956. Because exact fixed package versions are distribution-specific and were not provided, use the relevant Linux distribution security advisory or kernel changelog to identify the corrected kernel build. Prioritize systems that use CephFS, RBD, rados, Kubernetes or virtualization storage integrations backed by Ceph, or any service that loads and uses the in-kernel Ceph client. If immediate patching is not possible, reduce exposure by restricting Ceph protocol access to trusted cluster networks, blocking untrusted hosts from reaching Ceph monitor and storage service ports, avoiding connections to untrusted Ceph clusters, and unloading or disabling Ceph client functionality where not required. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the old kernel remains running.

How to confirm the fix worked

Confirm that affected systems are running a patched kernel, not only that a patched package is installed. Validate with commands such as uname -a, package-manager queries, and the Linux distribution's security advisory mapping for this CVE. Confirm whether the ceph, libceph, rbd, or ceph-related kernel modules are loaded, and verify whether the system mounts CephFS or RBD devices. Review kernel changelogs or vendor errata for the __ceph_x_decrypt() bounds-check fix. Where feasible, perform a controlled regression test by initiating Ceph authentication against a patched system and confirming no kernel warnings, KASAN reports, oopses, or authentication-path crashes occur.

Typical attack path

1. Identify a Linux system using the in-kernel Ceph client or mounting Ceph-backed storage.
2. Gain the ability to send Ceph protocol messages to that client, such as by controlling a Ceph endpoint, compromising part of the Ceph cluster, or positioning on the network path.
3. Trigger cephx authentication or re-authentication from the client.
4. Send a malformed encrypted authentication reply with a ciphertext length smaller than the expected ceph_x_encrypt_header size.
5. Cause __ceph_x_decrypt() to access memory beyond the provided buffer when reading the header magic field.
6. Induce kernel instability, authentication failure, or a denial-of-service condition on the affected client system.

How to detect it

Look for evidence of attempted exploitation or triggering in kernel logs, system journals, crash dumps, and Ceph client logs. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore data, KASAN reports, kernel oops traces, Ceph client logs, and network telemetry for Ceph monitor traffic. Focus on systems with CephFS mounts, RBD mappings, or loaded ceph/libceph kernel modules. Indicators include kernel faults in or near __ceph_x_decrypt(), ceph_x_decrypt(), cephx authentication handling, libceph, or repeated authentication failures immediately preceding a kernel oops, panic, reset, or node disappearance. Network-level detection is difficult without protocol-aware parsing, but suspicious patterns include unexpected Ceph authentication replies from untrusted hosts, malformed or unusually short authentication ciphertexts, and Ceph traffic from hosts that should not participate in the cluster.

• __ceph_x_decrypt
• ceph_x_decrypt
• libceph
• cephx
• ceph_x_encrypt_header
• hdr->magic
• FRAME_TAG_AUTH_REPLY_MORE
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• kernel BUG at
• general protection fault
• Oops:
• Kernel panic
• ceph: auth
• ceph: mon
• ceph: client
• rbd:
• ceph-fuse
• /sys/module/ceph
• /sys/module/libceph
• /proc/mounts ceph
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems using CephFS, RBD, or the in-kernel Ceph client, including container, virtualization, and storage platforms.
• Prioritize kernel updates on systems that connect to Ceph clusters or expose Ceph client functionality, then reboot into the fixed kernel.
• Restrict Ceph network access to trusted management and storage networks; do not allow untrusted systems to reach Ceph monitor or storage service ports.
• Monitor kernel logs for crashes or memory-safety reports involving __ceph_x_decrypt, cephx, libceph, or malformed Ceph authentication frames.
• Review Ceph cluster trust boundaries and investigate any unexpected Ceph endpoints, unauthorized monitor changes, or suspicious authentication failures.
• Because this is not currently KEV-listed and has low EPSS with no known mature exploit, handle through expedited patch management for Ceph-exposed systems rather than emergency internet-wide response.