PT-2026-90363 · Linux · Linux

CVE-2026-89647

·

Published

2026-09-11

·

Updated

2026-09-11

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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---
Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

CVE-2026-89647

Affected Products

Linux