The vulnerability arises from storing non‑negative values in signed 32‑bit integers during the decoding of Ceph monitor maps. Because blob_len and num_mon are declared as signed integers, an incoming unsigned value that is larger than 2^31–1 is interpreted as a negative number. The code later uses num_mon as an unsigned value when allocating memory for the monitor map, so a very large numeric value can cause the kernel to attempt to allocate an excessively large block of memory. This allocation fails, returning –ENOMEM; if the failure path is not handled correctly, it can trigger a denial‑of service by exhausting kernel resources or causing kernel instability.

This flaw affects any Linux kernel that includes the libceph component and implements the ceph_monmap_decode() routine. The kernel versions patched to change blob_len and num_mon from signed int to unsigned u32 are no longer vulnerable; ongoing vulnerability applies to all earlier kernel releases that have not applied the patch.

Based on the description, it is inferred that an attacker must be able to inject a crafted Ceph monitor map that contains an oversized num_mon value into a node running the affected kernel. The CVSS score of 7.0 indicates high severity, but the EPSS score is not available and the vulnerability is not listed in the CISA KEV catalog, which suggests limited known exploitation. The attack path is straightforward: send a monitor map with a num_mon value exceeding CEPH_MAX_MON to a Ceph client or server, triggering the kernel to attempt a large allocation and possibly fail, leading to a denial‑of‑service condition.