GPU VulnDB

Database/Control plane, storage & DevOps

Linux CephFS client: cap reclaim work busy-loops, burning CPU and contending dentry_list_lock

UnscoredCVE-2026-89647Control plane, storage & DevOpscurated

Impact

ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which it does whenever the lease walk exhausts its scan budget - including when there is no cap pressure and nothing to reclaim. The dir-lease walk made it worse by returning TOUCH for every valid lease, rewriting the list and refreshing timestamps so leases never aged out. The reporter measured 500 ceph_trim_dentries() calls per second on production servers, with heavy contention on mdsc->dentry_list_lock visible in lock_stat. On a GPU node with a CephFS mount this is steady background CPU burn and lock contention on the data path that feeds training jobs - a performance regression, not a security boundary crossing.

Who can reach it

Local and non-adversarial: any node with a CephFS mount holding many valid dentry leases and no cap pressure. No attacker involvement.

What to do

Patch the host kernel to a stable release carrying the KEEP-instead-of-TOUCH change and the -EAGAIN/bail-out conditions (commits below) and reboot the affected nodes. There is no configuration mitigation in the record. No vendor fixed-version string is given beyond the stable commits.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.