CVE-2026-89647

Received Received - Intake

Denial of Service in Linux Kernel CephFS

Publication date: 2026-09-11

Last updated on: 2026-09-11

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: ceph: do not repeat ceph_trim_dentries() if no progress possible ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately. The dir-lease walk made this worse. When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease. `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue. Fix this in three steps: - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is `false`. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via `STOP` at the first fresh lease). - Only return `-EAGAIN` from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead. - After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (`count==0`). There is no reason to keep retrying when we are not over the cap limit and made no progress. Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`. Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in `/proc/lock_stat` (5 minute capture): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 With this patch: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 1 ---truncated---

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-11

Last Modified

2026-09-11

Generated

2026-09-12

AI Q&A

2026-09-12

EPSS Evaluated

N/A

NVD

CVE-2026-89647

EUVD

EUVD-2026-76559

Affected Vendors & Products

Vendor	Product	Version / Range
ceph	ceph	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability in the Linux kernel's Ceph filesystem component involves a busy loop in ceph_cap_reclaim_work() that repeatedly calls ceph_trim_dentries() without making progress when no dentry reclamation is possible. The issue occurs because the function keeps re-queuing itself when ceph_trim_dentries() returns -EAGAIN, which happens when lease walks exhaust their scan budget without reclaiming anything. The dir-lease walk exacerbates this by unnecessarily resetting timestamps and churning the dentry list.

Detection Guidance

This vulnerability is specific to the Linux kernel's Ceph filesystem component and manifests as excessive CPU usage due to a busy loop in ceph_cap_reclaim_work(). To detect it, monitor for high CPU usage from ceph processes, particularly ceph_trim_dentries(), using tools like top, htop, or ps. Check /proc/lock_stat for contention on &mdsc->dentry_list_lock as shown in the CVE details.

Impact Analysis

This vulnerability can cause high CPU usage and performance degradation on systems running Ceph, particularly web servers. It leads to excessive CPU consumption with no functional benefit, as seen in the reported 500 ceph_trim_dentries() calls per second. The issue increases lock contention and latency, as shown by the lock statistics before and after the patch.

Mitigation Strategies

Apply the kernel patch that fixes this issue by updating to a version of the Linux kernel that includes the patch for ceph_cap_reclaim_work(). The fix changes the behavior of ceph_trim_dentries() to avoid unnecessary busy loops when no progress is possible. Check your distribution's security updates or kernel release notes for the patched version.

Hi! I’m here to help you understand CVE-2026-89647. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70