https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 21:51:29 +0000 https://vulnerability.circl.lu/vuln/cve-2025-39879 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: always call ceph_shift_unused_folios_left()</p> <p>The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array.</p> <p>However, since commit ce80b76dd327 (&#34;ceph: introduce ceph_process_folio_batch() method&#34;), this shifting doesn&#39;t happen anymore because the &#34;for&#34; loop got moved to ceph_process_folio_batch(), and now the `i` variable that remains in ceph_writepages_start() doesn&#39;t get incremented anymore, making the shifting effectively unreachable much of the time.</p> <p>Later, commit 1551ec61dc55 (&#34;ceph: introduce ceph_submit_write() method&#34;) added more preconditions for doing the shift, replacing the `i` check (with something that is still just as broken):</p> <p>- if ceph_process_folio_batch() fails, shifting never happens</p> <p>- if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens</p> <p>- if `processed_in_fbatch` is zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens</p> <p>Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way:</p> <p>BUG: kern…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: always call ceph_shift_unused_folios_left()</p> <p>The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array.</p> <p>However, since commit ce80b76dd327 (&#34;ceph: introduce ceph_process_folio_batch() method&#34;), this shifting doesn&#39;t happen anymore because the &#34;for&#34; loop got moved to ceph_process_folio_batch(), and now the `i` variable that remains in ceph_writepages_start() doesn&#39;t get incremented anymore, making the shifting effectively unreachable much of the time.</p> <p>Later, commit 1551ec61dc55 (&#34;ceph: introduce ceph_submit_write() method&#34;) added more preconditions for doing the shift, replacing the `i` check (with something that is still just as broken):</p> <p>- if ceph_process_folio_batch() fails, shifting never happens</p> <p>- if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens</p> <p>- if `processed_in_fbatch` is zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens</p> <p>Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way:</p> <p>BUG: kern…</p> https://vulnerability.circl.lu/vuln/cve-2025-39879