Linux libceph: integer overflow in osdmap decoding defeats the bounds check and reads out of bounds

Impact

The bounds check for the new_state section of a CEPH_MSG_OSD_MAP is computed by multiplying a length read out of the incoming message, and that multiplication can overflow, so an oversized len passes validation and decoding then reads past the end of the buffer. The fix switches to check_mul_overflow() and rejects such maps. The exposure is out-of-bounds reads in kernel context on every node running a kernel CephFS or RBD client, which in practice means a crashed node - and on a GPU host that is the loss of whatever job was resident plus a reboot to recover. As with the sibling libceph fixes, the NVD AV:N 9.8 rating assumes an attacker can already put a crafted osdmap in front of the client, which means a compromised or impersonated monitor or an unauthenticated storage network, not an arbitrary remote party.

Who can reach it

Whoever can hand the kernel client an OSD map: a compromised Ceph monitor, or an on-path attacker on a storage network where msgr2 authentication and encryption are not enforced. Not reachable from a tenant workload on the node.

What to do

Move to a stable kernel containing the fix (five backport commits are on the record) and reboot each node with a kernel Ceph mount; a mounted client rules out module reload, so plan drain-and-reboot and batch it with the other libceph fixes published the same day. In the interim, keeping clients on authenticated msgr2 over an isolated storage network is what actually keeps a crafted osdmap away from the decoder.

References