GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel libceph: oversized monitor count slips past the CEPH_MAX_MON check

CVSS 7.5CVE-2026-43405Kernel, userspace & hypervisorcurated

Impact

The kernel Ceph client behind CephFS mounts and RBD block devices stores the monitor count from an incoming monmap in a signed int. A very large value turns negative and passes the num_mon > CEPH_MAX_MON check. The kernel then tries to allocate a huge monmap. Per the fix description that allocation will most likely fail, and the client returns -ENOMEM where it should return -EINVAL. The record describes no memory corruption. The practical effect is a failed allocation attempt and the wrong error code when the client parses a bad monmap. The 7.5 network DoS score overstates what the description shows, so treat this as a hardening fix and not an emergency.

Who can reach it

A Ceph monitor, or anyone who can impersonate one or tamper with monitor traffic to the client node, has to send the crafted monmap. That means a compromised storage cluster or a position on the storage network. Only nodes that use the in-kernel CephFS or RBD client are exposed.

What to do

Take the stable kernel that carries the fix (commits referenced below) in your normal kernel cycle. That means draining and rebooting each node that mounts CephFS or maps RBD through the kernel client. Nodes that do not load libceph are unaffected. Given the limited impact, there is no reason to schedule an out-of-band window.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.