Linux kernel libceph: a monmap advertising zero monitors hits a BUG_ON and takes down the client node

Impact

ceph_monmap_decode() accepted a CEPH_MSG_MON_MAP carrying num_mon == 0, a state no real cluster can be in. When the client later opens a session, pick_new_mon() trips the BUG_ON(num_mon < 1) assertion and the kernel dies. Any GPU node that mounts CephFS or maps RBD in-kernel - for datasets, checkpoints or scratch - can be knocked over this way, and a BUG_ON is a hard kernel stop, so recovery means a reboot of the node with whatever training job was resident on it. The trigger is a corrupted or attacker-supplied monmap on the storage network, so the realistic prerequisite is a compromised or spoofed monitor rather than an arbitrary tenant. Availability only; no memory disclosure or privilege gain is described.

Who can reach it

Whoever can deliver a MON_MAP message to the kernel Ceph client - in practice a compromised or impersonated Ceph monitor, or an attacker able to inject on the unauthenticated storage network. Not reachable from inside a tenant GPU pod that has no direct Ceph mount.

What to do

Take the stable-kernel fix that extends the ceph_monmap_decode() check to reject num_mon == 0 (five stable branches carry it; see the git.kernel.org commits) and reboot each node running the kernel Ceph client - this is kernel code, so it means drain and reboot, not a service restart. Where a reboot cycle across the fleet is expensive, prioritise nodes whose Ceph traffic crosses a network that untrusted hosts share.

References

Related entries

• Linux kernel libceph: NULL dereference in CRUSH locality lookup when a parent bucket's type name is missingCVE-2026-68157 · Linux kernel libceph (get_immediate_parent CRUSH type name lookup)High
• Linux kernel (net/tls): A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitlyCVE-2026-72330 · Linux kernel (net/tls)High
• OpenSSL: SSL_set_SSL_CTX mid-handshake leaves a stale slot count, allowing heap OOB read/writeCVE-2026-72897 · OpenSSL TLS server (SSL_set_SSL_CTX certificate-slot array)High
• Linux kernel (drivers/nvme/target): A client that completes the TLS handshake against the NVMe-oF TCP target and thenCVE-2026-74385 · Linux kernel (drivers/nvme/target)High
• Linux kernel (drivers/nvme/target): Every connection that dies partway through queue allocation on the NVMe-oF TCPCVE-2026-74386 · Linux kernel (drivers/nvme/target)High
• Linux kernel libiscsi: out-of-bounds read leaks stale connection data into the SCSI sense bufferCVE-2026-74557 · Linux kernel libiscsi (SCSI Response sense-data bounds check)High