CVE Catalog

CVE-2026-89753

Low risk· EPSS 6%
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.17%

6th percentile - higher than 6% of all known CVEs

Summary

In the Linux kernel, the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. As a result, the reclaiming task never reports a Tasks-RCU quiescent state and becomes a holdout, causing rcu_tasks stalls during reclaim.

Risk Assessment

RCU stalls during memory reclaim can cause kernel warnings, delayed RCU synchronization, and degraded system stability and performance under memory pressure. This may lead to unpredictable application behavior.

Recommendation

Update the Linux kernel to a version containing the fix that replaces cond_resched() with cond_resched_tasks_rcu_qs() in shrink_lruvec(). Monitor logs for rcu_tasks stall messages after deployment.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]

Vulnerability data from NVD (NIST) · CISA KEV · EPSS