CVE-2026-43405

What it actually does

The flaw is a signedness conversion bug in the Linux kernel libceph monitor-map decoder. A 32-bit value from an incoming Ceph monitor map can be decoded into a signed integer, interpreted as negative, and bypass the intended upper-bound check against the maximum allowed monitor count. The value is then used in an unsigned allocation context, causing the kernel Ceph client to attempt an extremely large memory allocation. The likely result is allocation failure and an error path, but under pressure it can contribute to denial of service, failed Ceph client operations, mount/connect failures, or kernel memory exhaustion symptoms. The vulnerability affects availability; it does not directly provide confidentiality or integrity impact based on the published description.

Why it matters to the business

Systems that use the Linux kernel Ceph client, such as CephFS or RBD consumers, may be vulnerable to disruption if they process a malicious or malformed Ceph monitor map. Successful exploitation can interfere with storage connectivity and dependent workloads, causing application outages, failed mounts, degraded services, or operational instability. The issue has a network attack vector and requires no user interaction according to the CVSS vector, but current public exploitation indicators are low: EPSS is 0.0049, it is not listed in CISA KEV, it is not associated with known ransomware use, and no public exploit maturity is reported.

How an attack unfolds

An attacker needs a way to cause a vulnerable Linux kernel Ceph client to process a crafted Ceph monitor map. This could involve a malicious Ceph monitor endpoint, a compromised component in a Ceph environment, or another position from which the attacker can deliver malformed Ceph protocol data to the client. The attacker encodes an abnormally large 32-bit monitor count value. In vulnerable kernels, the value is stored in a signed integer, so very large unsigned values can appear negative and bypass the check that should reject monitor counts above the supported maximum. The value is later treated as unsigned during monitor-map allocation, leading the kernel client to attempt an excessive memory allocation. This can fail with an out-of-memory-style error and disrupt Ceph client initialization or operation, producing a denial-of-service condition rather than code execution.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the libceph ceph_monmap_decode() signedness fix. Because no exact fixed package versions were provided, use the relevant distribution or appliance vendor advisory to identify the corrected kernel build for each platform. Prioritize systems that mount CephFS, use kernel RBD, or otherwise rely on the in-kernel Ceph client. Where immediate patching is not possible, reduce exposure by restricting Ceph monitor traffic to trusted networks and trusted clients, preventing untrusted systems from impersonating or reaching Ceph monitor endpoints, enforcing network segmentation and authentication for Ceph services, and monitoring for repeated Ceph client connection failures or kernel memory-allocation errors. Mitigations reduce exploitability but do not replace the kernel fix.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that use the in-kernel Ceph client and checking their running kernel versions against the fixed versions published by the operating-system or kernel vendor. Validate remediation by confirming the active booted kernel is the patched build, not merely that an updated package is installed. On representative systems, verify CephFS mounts, RBD mappings, and Ceph-backed workloads operate normally after reboot. Review kernel changelogs or source package patches for the fix that changes non-negative decoded values in ceph_monmap_decode(), including blob_len and num_mon, to unsigned 32-bit handling. If feasible in a controlled test environment only, validate that malformed monitor maps are rejected cleanly rather than causing excessive allocation attempts or ENOMEM behavior.

Typical attack path

1. Identify hosts using the Linux kernel Ceph client, such as CephFS mounts or RBD-backed workloads.
2. Obtain a path to influence Ceph monitor-map data delivered to a vulnerable client, such as through a malicious, spoofed, or compromised Ceph monitor endpoint.
3. Send a crafted monitor map containing an extremely large 32-bit monitor count value.
4. Trigger ceph_monmap_decode() in the vulnerable kernel client as it parses the incoming monitor map.
5. Cause the monitor-count validation to be bypassed because the large unsigned value is interpreted as a negative signed integer.
6. Force an excessive memory allocation attempt during monitor-map handling.
7. Disrupt Ceph client connectivity or storage-dependent workloads through allocation failure, memory pressure, or repeated error handling.

How to detect it

Look for evidence that Linux Ceph clients processed malformed monitor-map data or experienced unusual memory-allocation failures while communicating with Ceph monitors. Useful sources include kernel logs, system journal, dmesg output, Ceph client logs where present, Ceph monitor logs, network telemetry for Ceph monitor ports, and endpoint telemetry showing mount or RBD mapping failures. Hunt for repeated Ceph client connection resets, authentication or monitor-map parsing failures, kernel ENOMEM messages near Ceph activity, OOM-killer activity involving Ceph-dependent processes, and sudden spikes in failed CephFS mounts or RBD map operations. Also investigate any unexpected Ceph monitor IP addresses, DNS changes, routing changes, or monitor membership changes that could indicate a malicious or compromised monitor source. There are no unique public exploit strings for this issue, so detection should correlate Ceph client errors, kernel memory pressure, and suspicious Ceph monitor communications rather than relying on a single signature.

• ceph_monmap_decode
• libceph
• monmap
• mon map
• ENOMEM
• Out of memory
• oom-killer
• Killed process
• ceph:
• rbd:
• cephfs
• failed to allocate
• failed to decode
• failed to get monmap
• mount error
• rbd: map failed
• msgr2
• tcp/3300
• tcp/6789

What your security team should do

• Prioritize patching Linux systems that use CephFS, kernel RBD, or other in-kernel Ceph functionality, especially production storage clients and highly available workload nodes.
• Use vendor kernel advisories to identify exact fixed builds and ensure systems are rebooted into the patched kernel after installation.
• Restrict access to Ceph monitor ports and management networks so only trusted clients and monitors can communicate with them.
• Investigate any unexpected Ceph monitor endpoint changes, certificate or authentication anomalies, or evidence that a Ceph monitor could have been spoofed or compromised.
• Monitor kernel logs for Ceph client decode errors, repeated ENOMEM allocation failures, OOM events, and Ceph mount or RBD mapping failures.
• Treat this as primarily an availability risk; prioritize based on dependency on Ceph-backed storage, exposure of Ceph networks, and tolerance for storage disruption.
• Because the vulnerability is not in CISA KEV, has no known ransomware association, and has low EPSS at publication+95 days, handle through accelerated routine patching unless Ceph client exposure is broad or externally reachable.