UBUNTU-CVE-2026-89647: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: ceph: do not repeat cephtrimdentries() if no progress possible cephcapreclaimwork() re-queues itself for as long as cephtrimdentries() returns -EAGAIN, which happens whenever a lease walk exhausts its nrtoscan 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 expiredirlease is false (i.e. we have no intention of reclaiming dir leases), dirleasecheck() returned TOUCH for every valid lease. TOUCH moves the dentry to the tail of the list and resets di->time via dentrydirleasetouch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained nrtoscan, guaranteeing the -EAGAIN requeue. Fix this in three steps: - Return KEEP instead of TOUCH when expiredirlease 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 cephtrimdentries() calls per second on our web servers. This is very visible in /proc/lockstat (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->dentrylistlock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentrylistlock 111736 [<000000007b11e319>] cephdentrydirleasetouch+0x7c/0xa8 &mdsc->dentrylistlock 2631 [<0000000050597999>] dentryleaseswalk+0x64/0x2c8 &mdsc->dentrylistlock 3878 [<00000000c0022f62>] cephdentryleasetouch+0x5c/0xa8 &mdsc->dentrylistlock 9973 [<000000002f27cb6f>] dentryleaseunlist+0x50/0xa0 ----------------------- &mdsc->dentrylistlock 123621 [<0000000050597999>] dentryleaseswalk+0x64/0x2c8 &mdsc->dentrylistlock 1822 [<000000007b11e319>] cephdentrydirleasetouch+0x7c/0xa8 &mdsc->dentrylistlock 2720 [<000000002f27cb6f>] dentryleaseunlist+0x50/0xa0 &mdsc->dentrylistlock 55 [<00000000c0022f62>] cephdentryleasetouch+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->dentrylistlock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentrylistlock 1029 [<000000003c9aea8a>] cephdentrydirleasetouch+0x7c/0xa8 &mdsc->dentrylistlock 1 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
When expire_dir_lease is false, have __dir_lease_check() return KEEP for valid leases so they remain in place instead of being moved to the tail and having their timestamps reset.
Ceph directory-lease walk expire_dir_lease = false: return KEEP instead of TOUCH - Configuration
After both walks, return success (0) when nothing was freed and there is no cap pressure (count==0). Do not return -EAGAIN merely because the first walk exhausted its scan budget without freeing anything; under real cap pressure (count>0), retain the existing retry behavior.
ceph_trim_dentries() return/retry behavior = return success (0) when count==0 and nothing was freed; return -EAGAIN from the first dentry-lease walk only when something was freed
Event History
Frequently Asked Questions
What conditions trigger the CPU-consuming loop?
The loop occurs when Ceph cap reclaim finds nothing reclaimable: cap pressure is zero and all scanned leases remain valid. A lease walk exhausts its scan budget, returns -EAGAIN, and the reclaim work is immediately queued again.
What access does an attacker need to exploit this issue?
The supplied severity vector identifies this as locally reachable with low privileges, with no user interaction required. The stated impact is availability only, specifically CPU consumption.
How can administrators recognize the affected behavior?
Affected systems can repeatedly run Ceph cap reclaim work while consuming CPU but making no reclaim progress. In the described case, scans repeatedly exhaust their budget while valid directory leases are retained.