Linux libceph: CRUSH map with a zero bucket type makes the mapper index the OSD weight array negatively

Impact

CRUSH bucket type 0 is reserved for devices and the mapper uses it to recognise leaves, but crush_decode() did not reject it, so a malformed CRUSH map makes the mapper treat a negative bucket ID as a device and pass it to is_out(), which indexes the OSD weight array out of bounds. This is kernel-context memory access on every machine holding a kernel CephFS or RBD mount, and the likely outcome is a kernel oops that takes the node down. On GPU nodes that mount Ceph for datasets and checkpoints, that is an unscheduled loss of whatever training was resident, and recovery is a reboot rather than a service restart. The NVD 9.8/AV:N score overstates reach: the map arrives from the cluster's monitors, so a real attacker needs a compromised or impersonated monitor, or an on-path position on a storage network that is not running msgr2 secure mode.

Who can reach it

Whoever can deliver an OSD map to the kernel client - in practice a compromised Ceph monitor, or an attacker on the storage network able to inject messages when authentication and encryption are not enforced. No tenant-side access to the GPU node is involved.

What to do

Take the stable kernel containing the fix (five backport commits are linked on the record) and reboot each affected node; there is no module reload path for a mounted Ceph client, so this is drain-and-reboot across the fleet and can ride along with the other libceph fixes published the same day. Where the fleet cannot be rebooted soon, the meaningful mitigation is making sure clients only talk to monitors over authenticated msgr2 on an isolated storage network, since the bug is only reachable through a crafted map.

References