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