CVE-2026-89646
Full vulnerability record from the local CVENow database.
Description
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.
View original CVE JSON
{
"id": "CVE-2026-89646",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2026-09-11T20:19:50.477",
"lastModified": "2026-10-19T09:18:01.820",
"vulnStatus": "Received",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix leaked inode reference on writeback abort at umount\n\nceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it\nbumps i_wrbuffer_ref (taking an ihold() on the 0->1 transition) and\nattaches the snap_context to folio->private. That claim is released only\nby ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from\nwritepages_finish().\n\nIn ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails -- which\nhappens during umount -- the request is aborted before submission: the\nalready-collected folios are only redirtied and unlocked, so\nwritepages_finish() never runs and the claim is leaked.\nredirty_page_for_writepage() -> folio_redirty_for_writepage() ->\nfilemap_dirty_folio() sets PG_dirty directly and does not go through\n->dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it.\nBecause every subsequent writeback also fails the osd_stopping_blocker,\ni_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the\ninode cannot be evicted:\n\n VFS: Busy inodes after unmount of ceph\n kernel BUG at fs/super.c:650!\n\nRelease the orphaned claim in the abort path before redirtying, via\nceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer\nreference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop\nthe snap_context reference -- i.e. do what writepages_finish() would have\ndone for these never-submitted folios.\n\nOnly the locked_pages entries are undone; folios still in the fbatch were\nnever dirty-cleared by this call (folio_clear_dirty_for_io() is the\nownership-transfer point, and a successful move NULLs the fbatch slot), so\nthey hold no claim this call owns."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"fs/ceph/addr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "fd7449d937e7fb3144770592927cf452bf66dbd3",
"lessThan": "ec32015a955c5d326c5e26610edfdcccd52f2314",
"versionType": "git",
"status": "affected"
},
{
"version": "fd7449d937e7fb3144770592927cf452bf66dbd3",
"lessThan": "ac7a5a5385762df458d10cccc086a4e079be7409",
"versionType": "git",
"status": "affected"
},
{
"version": "fd7449d937e7fb3144770592927cf452bf66dbd3",
"lessThan": "c25aee9c630fb86f98d79eccb75765067079b972",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"fs/ceph/addr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.15",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.15",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.18.50",
"lessThanOrEqual": "6.18.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.2.4",
"lessThanOrEqual": "7.2.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.3",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
}
]
},
"references": [
{
"url": "https://git.kernel.org/stable/c/ac7a5a5385762df458d10cccc086a4e079be7409",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/c25aee9c630fb86f98d79eccb75765067079b972",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/ec32015a955c5d326c5e26610edfdcccd52f2314",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
]
}