CVE-2026-46066: ceph: fix num_ops off-by-one when crypto allocation fails
ceph: fix numops off-by-one when crypto allocation fails
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In ceph_process_folio_batch(), when move_dirty_folio_in_page_array() fails after the folio has already been added to the batch, decrement ceph_wbc->num_ops back to the correct value before continuing, preventing the BUG_ON panic.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected scenario requires CephFS files protected with fscrypt. Exploitation is local and requires low privileges according to the CVSS vector, along with the ability to write the relevant files.
What conditions trigger the kernel panic?
A dirty folio that is not first in a batch must fail crypto bounce-buffer allocation and be discontiguous from the preceding folio in the batch. The issue can be reproduced by writing an fscrypt-enabled CephFS file in a repeating 4 KiB written, 4 KiB skipped pattern while gradually increasing memory pressure.
What is the observable impact?
The system can panic in ceph_submit_write() when its expected write-operation count does not match the number of submitted operations. The reported assertion is BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops).
What can be done before a fix is applied?
Avoid the stated trigger conditions where possible: writes to fscrypt-enabled CephFS files using alternating sparse 4 KiB write/skip patterns, particularly under increasing memory pressure. This reduces exposure to the documented reproduction path.