During normal writeback, Ceph’s move_dirty_folio_in_page_array() may fail to allocate bounce buffers for encrypted folios. The function ceph_process_folio_batch() reuses its return code variable without resetting it, so a failure propagates to the main kernel writeback loop. The loop cannot tolerate such errors, and the unhandled failure eventually triggers an unexpected kernel panic, terminating the system. While the kernel crash is not the only effect, this results in a denial of service by rendering the affected node inoperable. The description confirms that the error propagates into ceph_wbc.pages handling and can lead to an oops when ceph_allocate_page_array() encounters a bug.

All Linux kernel builds that include the Ceph writeback code with fscrypt support are potentially vulnerable. The advisory does not list specific version ranges, so any distribution that ships a Ceph module with file‑system encryption enabled should be considered at risk until the patch is applied. The precise affected releases are not specified in the provided data, therefore administrators should review the kernel version they are running against upstream commit c0d84c7 (or the Git reference in the advisory) to determine if the fix is present.

No CVSS, EPSS, or KEV data is available for this issue. The lack of an EPSS score and the absence from the CISA KEV catalog suggest that, so far, exploitation has not been observed or documented. However, the documented crash during normal write operations indicates a high impact. The likely attack vector involves triggering Ceph writes that use encryption; an attacker could achieve this remotely if a Ceph client is compromised, or locally if a user has write access to the mounted filesystem. This inference is based on the context that the problem arises in Ceph write operations with fscrypt, so any entity able to effect a write could potentially trigger the failure.