CVE-2026-89646: ceph: fix leaked inode reference on writeback abort at umount
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix leaked inode reference on writeback abort at umount
cephdirtyfolio() takes a wrbuffer claim on each newly dirtied folio: it bumps iwrbufferref (taking an ihold() on the 0->1 transition) and attaches the snapcontext to folio->private. That claim is released only by cephputwrbuffercaprefs(), which for a submitted write runs from writepagesfinish().
In cephsubmitwrite(), if cephincosdstoppingblocker() fails -- which happens during umount -- the request is aborted before submission: the already-collected folios are only redirtied and unlocked, so writepagesfinish() never runs and the claim is leaked. redirtypageforwritepage() -> folioredirtyforwritepage() -> filemapdirtyfolio() sets PGdirty directly and does not go through ->dirtyfolio, so cephdirtyfolio() is not re-entered to rebalance it. Because every subsequent writeback also fails the osdstoppingblocker, iwrbufferref 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 cephundowrbufferclaim(): detach the snapcontext, drop the wrbuffer reference (letting iwrbufferref reach 0 and iput() the inode), and drop the snapcontext reference -- i.e. do what writepagesfinish() would have done for these never-submitted folios.
Only the lockedpages entries are undone; folios still in the fbatch were never dirty-cleared by this call (foliocleardirtyforio() is the ownership-transfer point, and a successful move NULLs the fbatch slot), so they hold no claim this call owns.
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected by this failure mode?
Linux kernel systems using the Ceph filesystem are affected when writeback is aborted during unmount because the OSD stopping blocker cannot be acquired. The issue involves folios that were dirtied and had already obtained a write-buffer claim.
What symptoms indicate that a system has encountered the issue?
The write-buffer reference does not return to zero, leaving the inode held and unable to be evicted. Reported symptoms include "VFS: Busy inodes after unmount of ceph" followed by a kernel BUG at fs/super.c:650.
Will subsequent writeback attempts clear the leaked reference?
No. During unmount, subsequent writeback attempts also fail the OSD stopping blocker, so the write-buffer reference remains elevated and the inode hold is not released.