Skip to main content
VulnerabilityPublished Updated

CVE-2026-43405: Linux kernel · libceph: Use u32 for non-negative values in ceph_monmap_decode()

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.5 High · fixed in ee5588e2bc41acb73f6676c0520420c107cd0140 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 48% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ee5588e2bc41acb73f6676c0520420c107cd0140, ba0a4df8c563536857dcbf7b4dbd0f2a15f57ace, b268984ae88cb0dcd7a8e8263962c748448e26e8 +4
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 8 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < ee5588e2bc41acb73f6676c0520420c107cd0140
Fixed in
  • ee5588e2bc41acb73f6676c0520420c107cd0140
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < ba0a4df8c563536857dcbf7b4dbd0f2a15f57ace
Fixed in
  • ba0a4df8c563536857dcbf7b4dbd0f2a15f57ace
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < b268984ae88cb0dcd7a8e8263962c748448e26e8
Fixed in
  • b268984ae88cb0dcd7a8e8263962c748448e26e8
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < 770444611f047dbfd4517ec0bc1b179d40c2f346
Fixed in
  • 770444611f047dbfd4517ec0bc1b179d40c2f346
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < 86f7060cd638d6eb042e8ed780fb83a59ca0dcb3
Fixed in
  • 86f7060cd638d6eb042e8ed780fb83a59ca0dcb3
LinuxLinuxAffected
  • ≥ a5cbd5fc22d5043a8a76e15d75d031fe24d1f69c, < 08bc6173fd611ad5a40f472bf5f15b92aea0fe40
Fixed in
  • 08bc6173fd611ad5a40f472bf5f15b92aea0fe40

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.

References

Community reviews

Loading reviews…