Linux kernel libceph: short ciphertext causes out-of-bounds read of the ceph_x_encrypt_header

Impact

__ceph_x_decrypt() casts part of the message buffer to a ceph_x_encrypt_header and reads hdr->magic without checking that the plaintext is at least that large. A FRAME_TAG_AUTH_REPLY_MORE frame whose ciphertext is 8 bytes or less makes the kernel read past the allocation. The record describes an out-of-bounds read reached from the authentication handshake, so the exposure is on the client side of any node that mounts CephFS or maps RBD in-kernel - a crash or stray read in kernel context, not a stated privilege gain. On a GPU node that mounts a shared Ceph filesystem for datasets or checkpoints, the realistic outcome is a kernel oops that takes training jobs on that node with it.

Who can reach it

Whoever can answer the client's Ceph authentication handshake - a malicious or compromised Ceph monitor, or anyone positioned to inject frames on the storage network before the session is established. No credentials on the client are needed; the client reaches this code while it is still authenticating.

What to do

Update to a stable kernel carrying the bounds check (five stable commits are linked; the record names no single fixed release). Kernel change on every node that mounts Ceph in-kernel: drain the node and reboot. Until then, the usual containment is keeping monitor traffic on a trusted storage network; the record does not describe a mitigation that removes the bug.

References

Related entries

• Linux kernel CephFS: folios skipped for writeback are never put, leaking page referencesCVE-2026-52960 · Linux kernel ceph (writeback folio batch reference handling)High
• Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but neverCVE-2026-52974 · Linux kernel (net/tls)High
• OpenSSL DTLS: buffering future-epoch records retains a full 16 KB read buffer each, ~1200x memory amplificationCVE-2026-54874 · OpenSSL DTLS record layer (future-epoch record buffering during handshake)High
• OpenSSL: memory leak per handshake when a server staples an OCSP response with no entriesCVE-2026-54876 · OpenSSL X.509 verification (OCSP stapled-response check, X509_V_FLAG_OCSP_RESP_CHECK)High
• libssh: incorrect AES-GCM finalization removes integrity protection on SSH sessionsCVE-2026-59847 · libssh (AES-GCM finalization check, OpenSSL backend)High
• Xen (vRTC): Out-of-bounds read in vRTC emulation - hypervisor memory disclosure to a guestCVE-2026-62430 · Xen (vRTC)High