CVE-2026-43188

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: do not propagate page array emplacement errors as batch errors<br /> <br /> When fscrypt is enabled, move_dirty_folio_in_page_array() may fail<br /> because it needs to allocate bounce buffers to store the encrypted<br /> versions of each folio. Each folio beyond the first allocates its bounce<br /> buffer with GFP_NOWAIT. Failures are common (and expected) under this<br /> allocation mode; they should flush (not abort) the batch.<br /> <br /> However, ceph_process_folio_batch() uses the same `rc` variable for its<br /> own return code and for capturing the return codes of its routine calls;<br /> failing to reset `rc` back to 0 results in the error being propagated<br /> out to the main writeback loop, which cannot actually tolerate any<br /> errors here: once `ceph_wbc.pages` is allocated, it must be passed to<br /> ceph_submit_write() to be freed. If it survives until the next iteration<br /> (e.g. due to the goto being followed), ceph_allocate_page_array()&amp;#39;s<br /> BUG_ON() will oops the worker.<br /> <br /> Note that this failure mode is currently masked due to another bug<br /> (addressed next in this series) that prevents multiple encrypted folios<br /> from being selected for the same write.<br /> <br /> For now, just reset `rc` when redirtying the folio to prevent errors in<br /> move_dirty_folio_in_page_array() from propagating. Note that<br /> move_dirty_folio_in_page_array() is careful never to return errors on<br /> the first folio, so there is no need to check for that. After this<br /> change, ceph_process_folio_batch() no longer returns errors; its only<br /> remaining failure indicator is `locked_pages == 0`, which the caller<br /> already handles correctly.