GPU VulnDB

Database/Control plane, storage & DevOps

Linux CephFS client: leaked inode reference on aborted writeback panics the node at umount

UnscoredCVE-2026-89646Control plane, storage & DevOpscurated

Impact

When ceph_inc_osd_stopping_blocker() fails during umount, ceph_submit_write() aborts before submission and only redirties the collected folios, so writepages_finish() never runs and the wrbuffer claim taken by ceph_dirty_folio() is leaked along with its ihold(). Every subsequent writeback fails the same blocker, so i_wrbuffer_ref never returns to zero and the inode cannot be evicted, ending in "VFS: Busy inodes after unmount of ceph" and a BUG() at fs/super.c:650. That is a kernel panic on a routine unmount. On a GPU node that mounts CephFS for datasets or checkpoints, an operator draining the node for maintenance can crash it instead of cleanly releasing it, which turns a planned window into an unplanned one.

Who can reach it

Local: unmounting a CephFS mount that still has dirty page cache. No attacker and no authentication is involved - it is a reliability and availability defect triggered by ordinary umount timing.

What to do

Patch the host kernel to a stable release adding ceph_undo_wrbuffer_claim() in the abort path (commits below) and reboot affected nodes. Until then, sync and quiesce writers before unmounting CephFS on a node being drained. The record names no vendor fixed-version string beyond the stable commits.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.