CVE-2026-89753
NoneCVSS
—
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
Linux computers can become unresponsive for long periods when they run low on memory because a cleanup routine fails to tell the rest of the system it is safe to proceed.
- Exploitation
- Other
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw causes tasks in direct memory reclaim via shrink_lruvec() to omit RCU-tasks quiescent state reports on PREEMPTION kernels because only cond_resched() is called, allowing involuntary preemption to leave tasks as RCU holdouts and trigger stalls.
Why it matters to the business
Memory-intensive workloads on Linux systems can encounter extended stalls or unresponsiveness during reclaim, degrading availability and performance especially in large-scale deployments with high memory pressure.
How an attack unfolds
An attacker induces sustained memory pressure to drive repeated direct reclaim through shrink_node and shrink_lruvec without quiescent state reporting; on PREEMPTION kernels the reclaim task remains an RCU-tasks holdout, producing detectable stalls. No named threat actors or ransomware campaigns are associated.
How to fix it
Apply a kernel update that replaces cond_resched() with cond_resched_tasks_rcu_qs() inside shrink_lruvec() to ensure quiescent state reporting even when the scheduler does not reschedule.
How to confirm the fix worked
Inspect the mm/vmscan.c source for the updated cond_resched_tasks_rcu_qs() call in shrink_lruvec(); confirm absence of RCU-tasks stall warnings referencing shrink_lruvec, mem_cgroup_iter, and shrink_node after applying the change.
Typical attack path
- Create memory pressure to invoke direct reclaim
- Reach shrink_lruvec() during page allocation paths
- Trigger involuntary preemption without cond_resched_tasks_rcu_qs() reporting a quiescent state
- Allow RCU-tasks to detect the holdout task and log stalls
How to detect it
Search kernel logs and dmesg for RCU-tasks stall messages that list shrink_lruvec, mem_cgroup_iter, shrink_node, and do_try_to_free_pages in the call trace; correlate with high memory allocation activity.
What your security team should do
- Prioritize kernel upgrades containing the RCU-tasks quiescent state fix within standard patch windows
- Enable kernel logging of RCU stall events for ongoing monitoring
- Test memory-pressure workloads in staging to validate stall resolution before broad rollout
The record
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]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|