Cloudanix VulnDB

CVE-2026-89646

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux's Ceph storage code can cause the system to crash or get stuck when shutting down a storage connection after writing files.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A reference count leak on inodes occurs in ceph_dirty_folio when ceph_submit_write aborts due to ceph_inc_osd_stopping_blocker failure at umount; writepages_finish never runs, i_wrbuffer_ref never reaches zero, and the inode cannot be evicted, producing VFS busy-inode warnings and kernel BUG at fs/super.c:650.

Why it matters to the business

Ceph-mounted systems may panic or hang on unmount after write activity, causing service outages, delayed shutdowns, and requiring manual intervention or reboot to recover.

How an attack unfolds

A local user performs write operations on a Ceph filesystem, then triggers unmount; the abort path in ceph_submit_write redirties pages without releasing the wrbuffer claim, leaking references on every subsequent writeback attempt until the unmount fails with busy inodes.

How to fix it

Apply the upstream patch introducing ceph_undo_wrbuffer_claim in the abort path of ceph_submit_write; rebuild and deploy the fixed kernel, then reboot affected nodes.

How to confirm the fix worked

Confirm the patched kernel contains the ceph_undo_wrbuffer_claim call before redirty_page_for_writepage in the abort path; attempt unmount after writes and verify absence of VFS busy-inode messages and kernel BUG.

Typical attack path

  1. Obtain local shell on a system with Ceph mounted
  2. Generate dirty pages via writes to Ceph-backed files
  3. Initiate umount while writes are in flight
  4. Observe repeated osd_stopping_blocker failures and inode reference leaks
  5. Trigger kernel BUG or busy-inode condition on unmount completion

How to detect it

Search kernel logs and dmesg for 'Busy inodes after unmount of ceph' and 'kernel BUG at fs/super.c:650' messages around umount events; correlate with Ceph write activity preceding the unmount.

What your security team should do

  • Prioritize kernel update for all Ceph clients before next maintenance window
  • Add monitoring for 'VFS: Busy inodes after unmount of ceph' messages in dmesg
  • Test unmount behavior under write load in staging before production rollout

The record

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 packages

Ecosystem Package Introduced Fixed