Linux kernel libceph: truncated monitor reply decodes stale bytes from the reused buffer

Impact

handle_get_version_reply() bounded its decode by front_alloc_len - the size of the reused reply buffer - instead of front.iov_len, the bytes actually received. A truncated MON_GET_VERSION_REPLY therefore passes the length check and the second u64 is read from leftover bytes of an earlier message, an uninitialized kernel memory read whose value then feeds Ceph client logic. This only matters on nodes that mount CephFS or map RBD through the in-kernel client; GPU nodes that reach Ceph through librbd, ceph-fuse or an S3 gateway do not load this code. NVD scores it 8.6 with high availability impact, which is consistent with a client-side hang or crash on a node whose storage mount cannot be dropped without evicting the jobs using it.

Who can reach it

Whoever can answer as the Ceph monitor to the kernel client: a compromised MON, or an on-path attacker on the storage network where messenger v2 secure mode is not enforced. No credentials beyond what the mount already presents; no local access to the GPU node is required.

What to do

Take the stable-kernel update containing the fix (five stable commits are linked). This is a kernel change, so the rollout is drain the node and reboot it onto the patched kernel - or a live-patch stream if your vendor ships one. Where the reboot cannot be scheduled soon, reduce exposure by enforcing msgr2 secure mode between clients and monitors so an off-path attacker cannot forge truncated replies.

References