CVE-2026-43406

What it actually does

This vulnerability is an out-of-bounds read in the Linux kernel Ceph client library, libceph, in process_message_header(). A malformed Ceph message frame can cause the kernel to decode a message header from a control segment that is shorter than the expected header size, or from data that is not actually a valid message frame. Because the vulnerable parsing occurs before sufficient bounds validation, a remote peer able to send crafted Ceph protocol traffic to an affected kernel Ceph client may trigger reads outside the intended buffer. The likely technical outcomes are kernel memory disclosure through unintended reads and kernel instability or crash, resulting in denial of service. Integrity impact is not indicated by the vulnerability description.

Why it matters to the business

Systems using the Linux kernel Ceph client, including CephFS or RBD-backed workloads, may be exposed to remote crashes or possible sensitive memory disclosure if they communicate with a malicious, compromised, or spoofed Ceph peer. Operationally, exploitation could interrupt storage access, crash affected hosts, disrupt applications relying on network storage, and create incident-response workload around potential kernel memory exposure. Although the CVSS score is critical, this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so remediation should be prioritized for systems that use kernel Ceph functionality or communicate with less-trusted Ceph infrastructure.

How an attack unfolds

An attacker first needs a network position that allows them to send Ceph protocol messages to a vulnerable Linux kernel Ceph client, such as by operating a malicious Ceph endpoint, compromising a Ceph service, abusing misconfigured network exposure, or positioning as an on-path attacker where Ceph traffic is not adequately protected. The attacker then sends a crafted Ceph message frame where the control segment length is inconsistent with the expected message header size, or where another frame type is made to appear as a message frame. The vulnerable process_message_header() path attempts to decode the header before confirming that enough bytes are present. This can make the kernel read past the valid message buffer. Depending on kernel build, memory layout, hardening, and runtime conditions, exploitation may produce kernel warnings, KASAN reports, connection resets, kernel oops/panic, or unintended disclosure of adjacent kernel memory through protocol behavior or diagnostics.

How to fix it

Apply the Linux kernel update from the relevant operating system or kernel vendor that includes the libceph bounds check in process_message_header(). Because fixed versions were not provided in the input, use the vendor advisory for the deployed distribution, kernel stream, appliance, or cloud image to identify the exact patched package. Reboot into the patched kernel after installation; updating the package alone is insufficient if the running kernel is still vulnerable. Where immediate patching is not possible, reduce exposure by restricting Ceph protocol access to trusted hosts only, isolating Ceph networks, blocking untrusted access to common Ceph ports such as 3300, 6789, and storage daemon ranges such as 6800-7300 where applicable, enforcing authenticated and encrypted Ceph messenger configurations where supported, and avoiding connections from kernel Ceph clients to untrusted or unmanaged Ceph clusters. Disable or unmount unused CephFS/RBD kernel client functionality on systems that do not require it.

How to confirm the fix worked

Confirm that the installed and running kernel version matches a vendor-fixed build containing the libceph process_message_header() bounds check. Validate both the package version and the active kernel with standard system tools, and ensure the system has been rebooted into the updated kernel. Inventory whether Ceph kernel functionality is in use by checking for loaded ceph/libceph/rbd modules, active CephFS mounts, and mapped RBD devices. Confirm that network controls limit Ceph traffic to trusted cluster members and clients. Review vendor changelogs or source patches for references to preventing out-of-bounds reads in libceph process_message_header(). In test environments, prefer vendor regression tests or kernel self-test artifacts rather than running untrusted proof-of-concept traffic against production systems.

Typical attack path

1. Identify Linux systems using the kernel Ceph client, such as CephFS mounts or RBD devices.
2. Gain the ability to send Ceph protocol traffic to the vulnerable kernel client, commonly through a malicious or compromised Ceph monitor, OSD, MDS, gateway path, or network position.
3. Establish or influence a Ceph connection with the target kernel client.
4. Send a malformed message frame with a control segment smaller than the message header or with frame metadata that causes invalid header decoding.
5. Trigger the vulnerable process_message_header() parsing path in libceph.
6. Cause an out-of-bounds read that may lead to kernel crash, service disruption, or possible memory exposure.
7. Repeat against multiple clients or storage consumers to amplify operational impact.

How to detect it

To determine whether exploitation may already have occurred, review kernel and system logs for crashes or memory-safety reports involving libceph, ceph, rbd, or process_message_header(). Important sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, crash dump directories, kdump/vmcore records, kernel panic telemetry, EDR kernel-event telemetry, and Ceph client logs if collected. Look for KASAN, UBSAN, general protection fault, page fault, kernel oops, BUG, or panic entries occurring during Ceph connection setup or message processing. Correlate those events with network logs showing unexpected connections to Ceph ports, repeated Ceph session resets, malformed protocol traffic, or connections from unrecognized Ceph monitors, OSDs, MDS nodes, or network peers. If a crash occurred, preserve vmcore and kernel logs before reboot cycling overwrites evidence. Because the public description does not provide a stable attacker payload signature, detection should focus on kernel fault artifacts and anomalous Ceph protocol behavior rather than a single network byte pattern.

• process_message_header
• libceph
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• ceph
• rbd
• ceph_con_workfn
• ceph-msgr
• /var/log/kern.log
• /var/log/messages
• /proc/mounts
• /sys/bus/rbd/devices
• tcp/3300
• tcp/6789
• tcp/6800
• tcp/7300

What your security team should do

• Prioritize patching Linux systems that use CephFS, RBD, or other kernel Ceph client functionality, especially where they communicate across shared, multi-tenant, or less-trusted networks.
• Use distribution-specific security advisories to identify the exact fixed kernel packages and schedule reboots to activate the patched kernel.
• Inventory systems with loaded ceph, libceph, or rbd kernel modules and active CephFS/RBD usage to scope exposure.
• Restrict Ceph protocol access at firewalls, security groups, host firewalls, and network ACLs to known Ceph clients and cluster nodes only.
• Harden Ceph transport and authentication settings where supported, and avoid connecting kernel clients to untrusted Ceph endpoints.
• Review kernel logs for crashes, KASAN findings, oopses, or panics involving libceph or process_message_header(), especially after Ceph connection activity.
• Monitor Ceph network traffic for malformed frames, unexpected peers, repeated connection resets, or unusual traffic to Ceph monitor and daemon ports.
• Because this is not currently KEV-listed and EPSS is low, balance urgency with exposure: patch exposed Ceph clients promptly, and include non-Ceph systems in the normal kernel maintenance cycle.