CVE-2026-89657: libceph: validate OSD extent maps before cursor advance
In the Linux kernel, the following vulnerability has been resolved:
libceph: validate OSD extent maps before cursor advance
net/ceph/osdclient.c:osdsparseread() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUGON(!length) assertion in cephmsgdatanext() from the client receive path.
Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply.
Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor.
[ idryomov: perform sparseextentmapvalid() check a bit earlier, in CEPHSPARSEREADDATALEN instead of CEPHSPARSEREADDATAPRE state ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix that validates Ceph sparse extent maps (sparse-read replies) before advancing the message-data cursor, rejecting maps that overflow, move backwards, overlap, or extend outside the original sparse-read request range to prevent the BUG_ON(!*length) assertion in ceph_msg_data_next().
Linux kernel (Ceph client/libceph) Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request range = Implement sparse_extent_map_valid() validation before ceph_msg_data_next() cursor advance
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker must control, compromise, or otherwise send a malformed authenticated reply as a Ceph OSD peer. The affected target is a kernel Ceph client performing a sparse read.
What is the impact of a successful exploit?
A malformed sparse-read extent map can advance the client message-data cursor beyond the request buffer and trigger a kernel BUG_ON assertion in the receive path. This can crash the kernel Ceph client.
What malformed data is relevant for detection or filtering?
The problematic OSD reply contains sparse extents that overflow, move backward, overlap, or extend outside the original sparse-read request range. A far-forward nonzero extent offset with a matching total data length can trigger the failure.
What should be done if updates cannot be applied immediately?
Limit exposure to trusted, authenticated Ceph OSD peers and investigate any OSD that may be malicious or compromised. The supplied data identifies malformed sparse-read replies from authenticated OSD peers as the attack path.