CVE-2026-89657

What it actually does

The flaw permits a malicious authenticated Ceph OSD to supply a sparse-read reply containing non-monotonic, overlapping, or out-of-range extent offsets; the client advances its message-data cursor past the original request buffer and triggers the BUG_ON(!*length) assertion inside ceph_msg_data_next().

Why it matters to the business

Successful exploitation produces an immediate kernel panic on Ceph clients, causing unplanned downtime for any workloads that rely on Ceph-backed block, file, or object storage and requiring manual node recovery.

How an attack unfolds

An attacker who controls or has compromised an authenticated Ceph OSD constructs a sparse-read response that advertises a forward extent offset whose length matches the data supplied; the unvalidated reply reaches osd_sparse_read(), advances the cursor beyond the receive buffer, and forces the kernel into the assertion failure path.

How to fix it

Apply the upstream kernel patch that adds the sparse_extent_map_valid() check (performed in the CEPH_SPARSE_READ_DATA_LEN state) before any cursor advancement; rebuild and deploy the fixed kernel on all Ceph client nodes.

How to confirm the fix worked

Confirm the presence of the sparse_extent_map_valid() call in osd_client.c and verify that attempts to replay a crafted out-of-range extent map now return an error instead of advancing the cursor; monitor dmesg for absence of the former BUG_ON line after upgrade.

Typical attack path

1. Gain control of an authenticated Ceph OSD (via supply-chain compromise, credential theft, or insider access)
2. Craft a sparse-read reply whose extent map is either backward, overlapping, or extends outside the original request range
3. Transmit the malformed reply to a vulnerable kernel Ceph client during a sparse read operation
4. Client processes the reply without extent validation, advances the data cursor past the allocated buffer
5. ceph_msg_data_next() hits BUG_ON and the kernel panics

How to detect it

Search kernel logs and Ceph client traces for the strings ceph_msg_data_next, osd_sparse_read, and BUG_ON triggered during sparse-read handling; correlate with OSDs that suddenly emit replies containing extent offsets far outside prior request ranges.

What your security team should do

• Patch Ceph client kernels to the fixed version as the highest-priority action
• Restrict OSD-to-client authentication to the minimum necessary principals and rotate keys regularly
• Enable kernel panic and Ceph client crash logging to a central SIEM for rapid detection of exploitation attempts
• Consider rate-limiting or isolating OSD nodes that exhibit anomalous reply patterns until patches are universally deployed