Excessive Platform Resource Consumption within a Loop Affecting libperf package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-LIBPERF-19838067
- published16 Sept 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-89759 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 libperf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream libperf package and not the libperf package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup when scanning task stacks
Patch series "mm/kmemleak: avoid soft lockup when scanning task", v3.
kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads.
That prints the following message, depending on the workload+host configuration:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]
scan_block
kmemleak_scan
kmemleak_scan_thread
kthread
Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks
Patches 2-3 let the scan loops stop early once a scan is interrupted.
This patch (of 3):
kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point. On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread
A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section.
Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop(). This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2532495
- https://access.redhat.com/security/cve/CVE-2026-89759
- https://git.kernel.org/stable/c/1838c704bcb4fd3556cf67513c6f97a39099e35c
- https://git.kernel.org/stable/c/3fc8044251de21555fb02c365fa681bab8b0db55
- https://git.kernel.org/stable/c/5d10d4e19e6daa487f0cd0ea6cba472325de92f9
- https://git.kernel.org/stable/c/9a1b12c06c192290b8479de48f66f1e75d89c4b7