CVE-2026-43405: libceph: Use u32 for non-negative values in ceph_monmap_decode()
In the Linux kernel, the following vulnerability has been resolved:
libceph: Use u32 for non-negative values in cephmonmapdecode()
This patch fixes unnecessary implicit conversions that change signedness of bloblen and nummon in cephmonmapdecode(). Currently bloblen and nummon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in cephdecode32safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of nummon is further assigned to monmap->nummon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for nummon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for nummon > CEPHMAXMON 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.
Affected Software
Event History
Frequently Asked Questions
What input is needed to trigger the flawed validation?
An incoming message must contain a very large num_mon value. When decoded into a signed int, the value can be interpreted as negative and bypass the num_mon > CEPH_MAX_MON check.
What is the observed result of a successful trigger?
The kernel attempts to allocate an excessively large monmap allocation. The allocation will most likely fail, causing -ENOMEM to be returned where invalid input should have been rejected with -EINVAL.