CVE-2026-43405: Linux Kernel libceph DoS Vulnerability

CVE-2026-43405 Overview

CVE-2026-43405 is a Linux kernel vulnerability in the libceph subsystem, specifically within the ceph_monmap_decode() function. The flaw stems from implicit signedness conversions of the blob_len and num_mon variables, which are declared as signed int but receive u32 values from ceph_decode_32_safe(). When a crafted Ceph monitor message contains a very large value, the signed interpretation causes the num_mon > CEPH_MAX_MON bounds check to be bypassed. The kernel then attempts an oversized memory allocation, returning -ENOMEM instead of rejecting the malformed input with -EINVAL.

Critical Impact

A remote attacker controlling Ceph monitor traffic can trigger excessive kernel memory allocation attempts, leading to denial of service on systems using libceph clients.

Affected Products

• Linux kernel libceph subsystem (multiple stable branches receiving backports)
• Systems using Ceph distributed storage clients (CephFS, RBD, RADOS)
• Linux distributions shipping affected kernel versions

Discovery Timeline

• 2026-05-08 - CVE-2026-43405 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43405

Vulnerability Analysis

The vulnerability resides in ceph_monmap_decode(), which parses monitor map (monmap) messages received from Ceph monitors. The function declares blob_len and num_mon as signed int, yet assigns them values produced by ceph_decode_32_safe(), a helper that decodes unsigned 32-bit integers from the wire protocol [CWE-195: Signed to Unsigned Conversion Error].

When num_mon receives a value with the high bit set (greater than 0x7FFFFFFF), the signed interpretation produces a negative number. The validation check num_mon > CEPH_MAX_MON then evaluates to false because a negative signed integer is less than the positive CEPH_MAX_MON constant. Execution continues into the allocation path, where num_mon is implicitly converted back to unsigned for monmap->num_mon and the allocation size calculation, producing a request for several gigabytes of kernel memory.

Root Cause

The root cause is a type mismatch between the protocol decoding helpers and the local variables holding decoded values. Both blob_len and num_mon should be declared as u32 to match the unsigned semantics of ceph_decode_32_safe() and the destination field monmap->num_mon. The fix changes both variable declarations to u32, ensuring the bounds check operates on unsigned values and correctly rejects attacker-controlled large counts.

Attack Vector

Exploitation requires the attacker to deliver a crafted monitor map message to a Linux client that uses libceph. This typically requires network access to inject or substitute Ceph monitor traffic, for example through a malicious or compromised monitor endpoint. No authentication or user interaction is required once the malicious message reaches the vulnerable decode path. The result is a failed large allocation and an -ENOMEM return, consuming kernel memory pressure and producing client-side denial of service.

No verified public exploit code is available. See the upstream fix in Linux Kernel Commit 86f7060 and related stable backports for technical details.

Detection Methods for CVE-2026-43405

Indicators of Compromise

• Kernel log entries showing failed large-order memory allocations originating from ceph_monmap_decode or libceph call paths.
• Repeated -ENOMEM return values from Ceph client mount or connection attempts coinciding with monitor traffic.
• Unexpected disconnections or remounts of CephFS, RBD, or RADOS clients without corresponding monitor-side faults.

Detection Strategies

• Monitor dmesg and /var/log/kern.log for allocation failure warnings referencing libceph or ceph_monmap_decode.
• Inspect network traffic to Ceph monitor ports (6789/tcp, 3300/tcp) for malformed monmap messages or unexpected monitor endpoints.
• Audit kernel versions across the fleet to identify hosts running pre-patch builds with active libceph modules loaded.

Monitoring Recommendations

• Alert on kernel out-of-memory events on hosts running Ceph clients, correlating with monitor session activity.
• Track Ceph client connection failures and unexpected reconnect storms in storage telemetry.
• Capture and review monitor map message sizes at the network layer to identify anomalous protocol values.

How to Mitigate CVE-2026-43405

Immediate Actions Required

• Apply the upstream Linux kernel patches that change blob_len and num_mon to u32 in ceph_monmap_decode().
• Update to a stable kernel release that includes the fix commits referenced in the NVD entry for CVE-2026-43405.
• Restrict network reachability of Ceph monitor endpoints to trusted storage networks and authenticated clients.

Patch Information

The fix has been merged into multiple stable kernel branches. Relevant commits include Linux Kernel Commit 86f7060, Linux Kernel Commit 08bc617, Linux Kernel Commit 5f28066, Linux Kernel Commit 7704446, Linux Kernel Commit b268984, Linux Kernel Commit ba0a4df, and Linux Kernel Commit ee5588e. Consult your distribution's security tracker for backported package versions.

Workarounds

• Isolate Ceph monitor traffic on dedicated storage VLANs with strict firewall rules limiting source addresses to known monitors.
• Enable CephX authentication and verify monitor identities to reduce the risk of malicious monmap injection.
• Unload the libceph and dependent modules (ceph, rbd) on systems that do not require Ceph connectivity until patches are deployed.

# Configuration example: restrict Ceph monitor traffic and verify kernel version
uname -r
modinfo libceph | grep -E 'version|filename'

# Block untrusted sources from reaching Ceph monitor ports
iptables -A INPUT -p tcp -m multiport --dports 3300,6789 \
    -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 3300,6789 -j DROP

# Unload libceph on hosts that do not require Ceph clients
modprobe -r rbd ceph libceph