CVE-2026-89757: Linux Kernel Privilege Escalation Flaw

CVE-2026-89757 Overview

CVE-2026-89757 is a Linux kernel vulnerability in the multi-generational LRU (MGLRU) memory management subsystem. The flaw resides in the sort_folio() shortcut path that handles folios that have become unevictable while still residing on a generation list. The shortcut violates the PG_lru usage convention and mishandles folio->lru, which is reused to store folio->mlock_count for unevictable folios.

The result is a user-visible accounting bug. On munlock, the kernel decrements a poisoned mlock_count value derived from LIST_POISON2, fails to clear PG_mlocked, and leaves the folio unevictable with inflated Mlocked accounting until it is freed.

Critical Impact
Memory accounting corruption in the MGLRU path causes folios to remain incorrectly marked as unevictable, inflating Mlocked memory counters and creating race conditions with concurrent LRU isolation operations.

Affected Products

Linux kernel versions containing the MGLRU sort_folio() shortcut for unevictable folios
Distributions shipping affected mainline and stable kernel branches
Systems using multi-generational LRU memory reclaim

Discovery Timeline

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

Technical Details for CVE-2026-89757

Vulnerability Analysis

The defect lives in mm/vmscan.c within the MGLRU sort_folio() function [CWE-Kernel Vulnerability]. The shortcut attempts to move folios that are no longer evictable but remain on a generation list. It calls lru_gen_del_folio() while PG_lru is still set, breaking the standard LRU flag ordering convention.

Unevictable folios are not threaded on lists[LRU_UNEVICTABLE]. The kernel reuses folio->lru storage to hold folio->mlock_count, as documented in the comment inside lruvec_init(). Every legitimate transition to unevictable state initializes mlock_count explicitly: lru_add() sets it to zero, while __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio).

Root Cause

The sort_folio() shortcut initializes nothing. The preceding lru_gen_del_folio() call may have already poisoned folio->lru through list_del(). Consequently, mlock_count aliases LIST_POISON2 and reads as 0x122, or 290 decimal. On munlock, __munlock_folio() decrements this bogus count, observes a still-non-zero value, and returns before clearing PG_mlocked. The folio remains permanently unevictable, and Mlocked accounting stays inflated until the folio is freed.

Attack Vector

Local workloads that exercise mlock and munlock on systems running MGLRU can trigger the accounting corruption. Because the shortcut clears PG_lru after removing the folio from the generation list, a concurrent folio_test_clear_lru() from compaction or folio_isolate_lru() can succeed on a folio that has already been unlinked. This creates a race condition with unpredictable secondary effects in the reclaim and compaction paths.

The upstream fix removes the shortcut entirely. Affected folios are now isolated as common folios and culled by the generic shrink path, matching classical LRU behavior. Refer to the kernel commit fixing the issue for the source-level change.

Detection Methods for CVE-2026-89757

Indicators of Compromise

Unexpectedly high Mlocked values in /proc/meminfo that do not correspond to active mlock() reservations
Folios that remain unevictable after successful munlock() calls
Kernel warnings related to PG_lru flag state during compaction or folio isolation
Discrepancies between reported process locked memory and actual usage under MGLRU-enabled kernels

Detection Strategies

Audit installed kernel versions against the fixed commits published in the stable kernel git tree
Monitor system memory accounting counters for drift between Mlocked and process-attributed locked pages
Enable CONFIG_DEBUG_VM in test environments to surface LRU state inconsistencies
Correlate reclaim slowdowns with elevated unevictable page counts that persist across workload cycles

Monitoring Recommendations

Collect kernel logs for messages originating from mm/vmscan.c and the MGLRU subsystem
Track /proc/vmstat fields including nr_unevictable and nr_mlock over time for anomalous growth
Alert on memory reclaim regressions on hosts running MGLRU-enabled kernel builds
Baseline unevictable memory usage per workload to detect accumulation patterns tied to this defect

How to Mitigate CVE-2026-89757

Immediate Actions Required

Identify hosts running Linux kernels with MGLRU enabled and the vulnerable sort_folio() shortcut
Apply the upstream stable kernel patches referenced in the kernel git commits
Prioritize patching on hosts running workloads that heavily use mlock() and munlock()
Validate distribution vendor advisories for backported fixes matching your kernel branch

Patch Information

The fix is available in the mainline and stable kernel trees. Relevant commits include 15d3a2a71c8b, 54a58d6656dd, and f7e698e326b2. The patch removes the buggy shortcut and routes unevictable folios through the generic shrink path.

Workarounds

Disable MGLRU by setting echo n > /sys/kernel/mm/lru_gen/enabled on kernels where the toggle is available
Reboot affected hosts periodically to reset inflated Mlocked accounting until patches are deployed
Reduce reliance on mlock() in application workloads where feasible until the kernel is updated
Restrict local access on shared systems to limit exposure to the accounting corruption path

bash

# Check current kernel version and MGLRU state
uname -r
cat /sys/kernel/mm/lru_gen/enabled

# Temporary workaround: disable MGLRU (requires root)
echo n > /sys/kernel/mm/lru_gen/enabled

# Verify Mlocked accounting
grep -E 'Mlocked|Unevictable' /proc/meminfo