CVE-2026-89646

Status: UPDATED  |  Advisory ID: CVE-2026-89646

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References