CVE-2026-89757: mm/mglru: fix and remove redundant unevictable folio handling
In the Linux kernel, the following vulnerability has been resolved:
mm/mglru: fix and remove redundant unevictable folio handling
sortfolio() 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 PGlru usage convention, and it has a more serious issue.
Unevictable folios are not threaded on lists[LRUUNEVICTABLE], so that folio->lru can be reused to hold folio->mlockcount (see the comment in lruvecinit()). Hence lruvecaddfolio() skips the listadd() for them, and every other place that turns a folio unevictable initialises mlockcount explicitly: lruadd() sets it to 0, mlockfolio() and mlocknewfolio() set it to !!foliotestmlocked(folio). sortfolio() sets nothing, and the lrugendelfolio() right above it may have already poisoned folio->lru via listdel(), so mlockcount ends up aliasing LISTPOISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, munlockfolio() decrements that bogus count, finds it still non-zero and bails out before clearing PGmlocked, 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 lrugendelfolio() while PGlru is still set, so a concurrent foliotestclearlru() (e.g. compaction, folioisolatelru()) 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 Software
Event History
Frequently Asked Questions
Which systems and workloads are most likely to encounter this issue?
The issue affects Linux kernel memory-management paths involving multi-generation LRU and folios that become unevictable while still on a generation list. Workloads that lock and later unlock memory through mlock/munlock are relevant to the user-visible failure described.
What condition triggers the incorrect state?
A folio must no longer be evictable while it remains on a generation list, causing the affected shortcut to handle it without initializing its mlock count. A later munlock can then decrement a bogus nonzero count and exit without clearing the mlocked state.
How could an administrator identify that the problem has occurred?
The described symptom is that memory remains unevictable after munlock and mlocked-memory accounting stays inflated. This can appear as folios retaining their mlocked state when they should have been released.
Is a fix available?
The vulnerability is described as resolved, and three stable kernel commit references are provided. No affected or fixed kernel version ranges are supplied in the available data.