Description
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.
Published: 2026-09-11
Score: 5.3 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Memory exhaustion / Denial of Service
Action: Apply Patch
AI Analysis

Impact

A bug in mm/mglru of the Linux kernel allows unevictable folios to be incorrectly handled during sorting. The faulty shortcut leaves the mlock_count field aliased to a list poison value, which is interpreted as a large numeric count. As a result, pages that should be reclaimable stay flagged as unevictable, inflating the kernel’s memory accounting and preventing those pages from being evicted. The bug can also reorder LRU flag updates, creating race conditions that may cause pages to be prematurely removed from generation lists, leading to unpredictable memory management behavior. The overall impact is potential memory exhaustion and degradation of system performance.

Affected Systems

All Linux kernel builds that do not include the upstream commit which removes the redundant unevictable folio handling are impacted. The affected products are identified as Linux:Linux, covering all distributions shipping an unpatched kernel. Once the patch is applied, the vulnerability is eliminated.

Risk and Exploitability

The CVSS score of 5.3 places this vulnerability in the medium severity range. The EPSS score of <1% indicates a very low exploitation probability and it is not listed in CISA KEV. The most probable attack vector is local to the system, inferred that an attacker with the ability to invoke mlock() and munlock() could repeatedly lock and unlock pages, causing the kernel to continually inflate the mlock_count field and exhaust free memory over time. The lack of a high EPSS score suggests that widespread exploitation is unlikely.

Generated by OpenCVE AI on September 15, 2026 at 20:11 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that contains the mm/mglru commit that fixes unevictable folio handling.
  • If a kernel upgrade is not yet possible, apply the upstream patch from the kernel source tree that implements the fix and rebuild any dependent modules.
  • Limit or audit the use of mlock() to restrict the number of pages an application can lock, and monitor the locked‑page count for abnormal growth until the fix is in place.

Generated by OpenCVE AI on September 15, 2026 at 20:11 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 12 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-911
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H'}

threat_severity

Moderate

Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description 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.
Title mm/mglru: fix and remove redundant unevictable folio handling
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-11T19:46:59.830Z

Reserved: 2026-09-11T19:38:34.763Z

Link: CVE-2026-89757

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:20:06.767

Modified: 2026-09-11T20:20:06.767

Link: CVE-2026-89757

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:46:59Z

Links: CVE-2026-89757 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-15T20:15:14Z

Weaknesses
  • CWE-911

    Improper Update of Reference Count