This CVE (CVSS 8.6) reveals a buffer boundary semantics error in libceph's handle_get_version_reply() handler. The function decoded a message structure assuming the receive buffer contained the full expected payload, when actually only front.iov_len bytes arrived. Under message truncation — a condition achievable by a man-in-the-middle dropping a TCP segment — the code read past the received data into stale buffer contents from previous message exchanges. That leaked kernel heap memory out through the network to whatever peer received the response.
The root cause is straightforward: the developer passed front_alloc_len (pre-allocated buffer size) to ceph_decode_need() instead of front.iov_len (actual received bytes). The fix is a one-line correction. But the deeper problem is that libceph's message handling API permits this error trivially — both values are available at the call site and neither the compiler nor the API enforces which is correct for decode boundaries. This isn't a one-off mistake; it's an architectural condition that other handlers have already gotten wrong in similar ways. The fix patches this instance; it does not retire the dangerous capability.
What you should do: audit every call to ceph_decode_need() and similar decode helpers in your libceph deployment. Verify each passes msg->front.iov_len (received byte count) rather than msg->front_alloc_len (buffer size). Prioritize the monitor reply path — monitors are the Ceph cluster's authority plane, and the stale heap data may contain authentication state, PG maps, or OSD topology from prior operations. If an attacker can inject truncation on the internal cluster network (modest barrier), they get a repeatable memory read against any client using this code path.
The longer-term concern: this API accepts either length parameter without type distinction or runtime assertion. Until that's redesigned, every new message handler inherits the same confusion risk. Consider adding a static analysis rule or review checklist flagging any decode call that uses *_alloc_len — enforcing that only receive-length semantics are permitted at decode boundaries.