{"id":21679,"date":"2026-09-12T04:31:30","date_gmt":"2026-09-11T20:31:30","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89757"},"modified":"2026-09-12T04:31:30","modified_gmt":"2026-09-11T20:31:30","slug":"cve-2026-89757","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89757","title":{"rendered":"CVE-2026-89757 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nmm\/mglru: fix and rem"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm\/mglru: fix and remove redundant unevictable folio handling<\/p>\n<p>sort_folio() has a shortcut for moving folios that are no longer evictable<br \/>\nbut are still sitting on a generation list.  However, this shortcut is<br \/>\nbuggy.  It does not follow the PG_lru usage convention, and it has a more<br \/>\nserious issue.<\/p>\n<p>Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that<br \/>\nfolio-&gt;lru can be reused to hold folio-&gt;mlock_count (see the comment in<br \/>\nlruvec_init()).  Hence lruvec_add_folio() skips the list_add() for them,<br \/>\nand every other place that turns a folio unevictable initialises<br \/>\nmlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and<br \/>\n__mlock_new_folio() set it to !!folio_test_mlocked(folio).  sort_folio()<br \/>\nsets nothing, and the lru_gen_del_folio() right above it may have already<br \/>\npoisoned folio-&gt;lru via list_del(), so mlock_count ends up aliasing<br \/>\nLIST_POISON2, which reads as 0x122, i.e.  290.  The result is user<br \/>\nvisible.  On munlock, __munlock_folio() decrements that bogus count, finds<br \/>\nit still non-zero and bails out before clearing PG_mlocked, so the folio<br \/>\nremains unevictable and the Mlocked accounting stays inflated until the<br \/>\nfolio is freed.<\/p>\n<p>The shortcut also touches the LRU flags in the wrong order.  It calls<br \/>\nlru_gen_del_folio() while PG_lru is still set, so a concurrent<br \/>\nfolio_test_clear_lru() (e.g.  compaction, folio_isolate_lru()) can succeed<br \/>\non a folio that has already been taken off the generation list, which may<br \/>\nlead to unexpected behavior.<\/p>\n<p>So fix it by isolating them as common folios and letting the generic<br \/>\nshrink path cull them.  This matches the classical LRU behavior, and there<br \/>\nshould be no visible effect on the generic eviction or isolation behavior.<\/p>\n<p>There is no performance concern either, such a folio goes through this<br \/>\nonce, and then it is off the generation lists for good.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm\/mglru: fix and remove redundant unevictable folio handling<\/p>\n<p>sort_folio() has a shortcut for moving folios that are no longer evi<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21679","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21679","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21679"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21679"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21679"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}