CVE-2026-89753: Linux Kernel Race Condition Vulnerability

CVE-2026-89753 Overview

CVE-2026-89753 is a Linux kernel defect in the memory management subsystem. The flaw resides in the shrink_lruvec() function of mm/vmscan.c, which drives direct memory reclaim. During long reclaim scans, the loop only invokes cond_resched(), which is a no-op on kernels built with PREEMPTION. Because involuntary preemption is not a Tasks-RCU quiescent state, a task performing direct reclaim can become an RCU-tasks holdout. Meta engineers observed rcu_tasks detected stalls on production fleet hosts, with call traces originating from handle_mm_fault through __alloc_frozen_pages_noprof into shrink_lruvec.

Critical Impact
The stall can block RCU-tasks grace periods, delay trampoline teardown, and degrade system stability under memory pressure on PREEMPTION kernels.

Affected Products

Linux kernel builds compiled with CONFIG_PREEMPTION that include the pre-patch mm/vmscan.c reclaim loop
Enterprise and cloud distributions shipping affected mainline and stable kernel branches
Workloads running under memory pressure that trigger direct reclaim through try_to_free_pages()

Discovery Timeline

2026-09-11 - CVE-2026-89753 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89753

Vulnerability Analysis

The defect is a scheduler and RCU interaction bug in the direct reclaim path. When a task allocates memory and the system is low on free pages, the kernel calls try_to_free_pages(), which walks memory cgroups through mem_cgroup_iter() and invokes shrink_node() then shrink_lruvec(). The reclaim scan can process large LRU lists before returning.

Inside the loop, the kernel calls cond_resched() to yield when necessary. On PREEMPTION kernels, that call reduces to a no-op because the scheduler already handles preemption points. Tasks-RCU, however, waits for tasks to voluntarily pass through a quiescent state. Involuntary preemption does not count. A reclaiming task therefore never signals a Tasks-RCU quiescent state and appears as a holdout, producing kernel messages such as INFO: rcu_tasks detected stalls on tasks.

The fix replaces the call with cond_resched_tasks_rcu_qs(), which explicitly reports a Tasks-RCU quiescent state even when no reschedule is needed.

Root Cause

The root cause is a missing Tasks-RCU quiescent state annotation in a long-running kernel loop. The reclaim path assumed that cond_resched() would provide sufficient scheduling and RCU progress, which is not true under CONFIG_PREEMPTION.

Attack Vector

This is a reliability and stability defect rather than a privilege-boundary vulnerability. Workloads that generate sustained memory pressure, such as page-fault-heavy multithreaded processes, can trigger the stall. There is no indication of remote exploitability or memory corruption. The defect can contribute to denial-of-service conditions when reclaim tasks block RCU-tasks grace periods on affected kernels.

See the upstream kernel commit 029c9408049f for the patch that converts cond_resched() to cond_resched_tasks_rcu_qs() in shrink_lruvec().

Detection Methods for CVE-2026-89753

Indicators of Compromise

Kernel log entries containing INFO: rcu_tasks detected stalls on tasks with call traces including shrink_lruvec, shrink_node, mem_cgroup_iter, or try_to_free_pages
Holdout tasks in the R running task state with growing nvcsw counters and idle_cpu: -1 fields
Periodic stall reports on hosts running PREEMPTION kernels under memory pressure

Detection Strategies

Parse dmesg and /var/log/messages for rcu_tasks detected stalls and correlate stack frames with the reclaim path
Track kernel version and CONFIG_PREEMPTION state across the fleet to identify hosts running pre-patch builds
Alert on prolonged try_to_free_pages latency using kernel tracepoints or bpftrace scripts

Monitoring Recommendations

Ship kernel logs to a centralized analytics pipeline and build dashboards for RCU stall frequency by host and kernel build
Monitor memory pressure signals such as PSI (/proc/pressure/memory) to identify hosts most likely to hit the reclaim path
Track RCU grace period duration through /sys/kernel/debug/rcu/ to catch delayed grace periods early

How to Mitigate CVE-2026-89753

Immediate Actions Required

Inventory Linux hosts by kernel version and identify builds that predate the fix on affected stable branches
Apply the stable kernel update that includes the cond_resched_tasks_rcu_qs() change in shrink_lruvec()
Schedule staged reboots on hosts running memory-intensive workloads that trigger frequent direct reclaim

Patch Information

The upstream fix is distributed across multiple stable branches. Reference commits include 029c9408049f, 25f52e812168, 3fd502399863, 4cdc1bdf4094, 4f50593c9cbc, a67a00a70a7c, b5391676c61d, and cf3ba0911a1c. Consume the fix through your distribution's kernel updates.

Workarounds

Reduce sustained memory pressure by tuning cgroup limits and vm.swappiness to avoid prolonged direct reclaim
Increase available memory headroom on hosts running latency-sensitive workloads until the patched kernel is deployed
Where feasible, evaluate non-PREEMPTION kernel builds for workloads that reproduce the stall, understanding the latency tradeoffs

bash

# Verify installed kernel version and preemption configuration
uname -r
grep CONFIG_PREEMPTION /boot/config-$(uname -r)

# Search recent kernel logs for the stall signature
dmesg -T | grep -E 'rcu_tasks detected stalls|shrink_lruvec'