CVE-2026-89657

The Linux kernel's libceph sparse-read path (osd_sparse_read() in net/ceph/osd_client.c) validated that the total sparse-read data length matched the summed extent lengths, but did not check that each OSD-supplied extent was monotonic and lay inside the original request range. A malformed yet properly authenticated sparse-read reply from a malicious or compromised Ceph OSD can advertise a far-forward extent offset with a matching data length, pushing the client's message-data cursor past the request buffer and tripping the BUG_ON(!*length) assertion in ceph_msg_data_next(), crashing the kernel client. The impact is availability only (kernel client crash/DoS, CVSS 3.1 7.5 with A:H and no C/I impact), and although the CVSS vector scores it PR:N, exploitation realistically requires control of an authenticated OSD peer — i.e., a compromised OSD host or malicious actor inside the cluster's trust boundary. Affected systems are hosts running Linux kernels with libceph sparse-read support that use kernel RBD block devices or CephFS kernel mounts against a Ceph cluster. No public PoC or in-the-wild exploitation is known, and the flaw is not listed in CISA's KEV catalog.

What to do: Apply a kernel update containing the fix — rejection of sparse extent maps that overflow, move backwards, overlap, or extend beyond the original sparse-read request — as soon as your distribution ships it. Until patched, consider routing affected workloads through userspace Ceph clients (librbd via QEMU, ceph-fuse) instead of kernel RBD mappings or CephFS kernel mounts, and harden the cluster itself (restrict Ceph/ms network access, enforce cephx and messenger encryption, monitor OSD hosts) since exploitation requires a malicious or compromised authenticated OSD. Watch kernel logs on Ceph client hosts for BUG_ON/panic traces through ceph_msg_data_next()/osd_sparse_read() as evidence of attempted triggering.