CVE-2026-89646

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix leaked inode reference on writeback abort at umount

ceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it bumps i_wrbuffer_ref (taking an ihold() on the 0->1 transition) and attaches the snap_context to folio->private. That claim is released only by ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from writepages_finish().

In ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails – which happens during umount – the request is aborted before submission: the already-collected folios are only redirtied and unlocked, so writepages_finish() never runs and the claim is leaked. redirty_page_for_writepage() -> folio_redirty_for_writepage() -> filemap_dirty_folio() sets PG_dirty directly and does not go through ->dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it. Because every subsequent writeback also fails the osd_stopping_blocker, i_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the inode cannot be evicted:

VFS: Busy inodes after unmount of ceph kernel BUG at fs/super.c:650!

Release the orphaned claim in the abort path before redirtying, via ceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer reference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop the snap_context reference – i.e. do what writepages_finish() would have done for these never-submitted folios.

Only the locked_pages entries are undone; folios still in the fbatch were never dirty-cleared by this call (folio_clear_dirty_for_io() is the ownership-transfer point, and a successful move NULLs the fbatch slot), so they hold no claim this call owns.

Affected Software

References

• https://git.kernel.org/stable/c/ac7a5a5385762df458d10cccc086a4e079be7409
• https://git.kernel.org/stable/c/c25aee9c630fb86f98d79eccb75765067079b972
• https://git.kernel.org/stable/c/ec32015a955c5d326c5e26610edfdcccd52f2314