CVE-2026-43405
Received Received - Intake
Integer Overflow in Linux Kernel Ceph Monmap Decode

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
CVE-2026-43405
EUVD
EUVD-2026-28711
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's libceph component, specifically in the ceph_monmap_decode() function. The issue arises because two variables, blob_len and num_mon, are declared as signed integers but are used to hold values that should always be non-negative (unsigned). These variables receive values from ceph_decode_32_safe(), which assigns unsigned 32-bit values (u32).

Because blob_len and num_mon are signed, very large values can be misinterpreted as negative numbers. This causes the check for num_mon being greater than the maximum allowed number of monitors (CEPH_MAX_MON) to fail to catch invalid large values. As a result, the system attempts to allocate an excessively large amount of memory for the monmap structure, which usually fails and returns an -ENOMEM error instead of the correct -EINVAL error.

The fix involves changing the types of blob_len and num_mon from signed int to unsigned 32-bit integers (u32) to correctly represent non-negative values and prevent improper memory allocation attempts.


How can this vulnerability impact me? :

This vulnerability can lead to improper handling of large values in the ceph_monmap_decode() function, causing the system to attempt to allocate an excessively large amount of memory. This allocation attempt is likely to fail, resulting in an -ENOMEM error.

While this does not directly cause a security breach like code execution or data corruption, it can lead to denial of service conditions by exhausting system memory or causing unexpected failures in the Ceph monitor map decoding process.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart