Cloudanix VulnDB

CVE-2026-89757

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel tracks certain locked memory pages can cause the system to keep those pages locked after they should be unlocked, leading to incorrect memory accounting and possible unexpected behavior under load.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The sort_folio shortcut in mm/mglru mishandles unevictable folios by failing to initialize mlock_count after list_del poisoning and by clearing LRU flags in an order that permits concurrent folio_test_clear_lru to succeed on an already-isolated folio.

Why it matters to the business

Linux systems may experience inflated Mlocked memory accounting and unexpected folio eviction or isolation behavior under memory pressure, potentially affecting stability and resource reporting on servers and embedded devices.

How an attack unfolds

An attacker with local code execution triggers concurrent memory-management operations (compaction or LRU isolation) while the kernel runs the buggy shortcut path, causing mlock_count to alias LIST_POISON2 and leaving PG_mlocked set after munlock, or producing inconsistent LRU state.

How to fix it

Upgrade to a kernel containing the fix that routes unevictable folios through the generic shrink path instead of the shortcut; rebuild and reboot with the corrected mm/mglru code.

How to confirm the fix worked

Confirm the patch is applied by inspecting the mm/mglru.c sort_folio function for removal of the shortcut and by running memory-pressure workloads that exercise mlock/munlock with concurrent compaction to verify correct PG_mlocked clearing.

Typical attack path

  1. Obtain local execution on an affected Linux kernel
  2. Allocate and mlock memory to place folios on generation lists
  3. Trigger munlock while concurrent compaction or folio isolation runs
  4. Exploit the resulting non-zero mlock_count or LRU flag inconsistency to interfere with memory reclamation or cause accounting errors

How to detect it

Examine kernel logs for warnings or oopses around folio isolation or mlock operations; search for processes that repeatedly mlock/munlock large regions while memory compaction is active; no public exploit artifacts are known.

What your security team should do

  • Prioritize kernel updates on multi-tenant and high-memory-pressure hosts
  • Monitor upstream stable branches for the mm/mglru backport
  • Audit custom kernels or embedded images that carry the affected mglru code
  • Review memory-accounting telemetry for sudden Mlocked inflation after munlock operations

The record

In the Linux kernel, the following vulnerability has been resolved: mm/mglru: fix and remove redundant unevictable folio handling sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior. So fix it by isolating them as common folios and letting the generic shrink path cull them. This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior. There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good.

Affected packages

Ecosystem Package Introduced Fixed