CVE-2026-89757 in Linux
摘要
由 VulDB • 2026-09-11
在 Linux 内核中，已修复以下漏洞：
mm/mglru: 修复并移除冗余的不可回收 folio（folio）处理逻辑
sort_folio() 函数为那些不再可被换出但仍驻留在生成列表上的 folios 提供了一个快捷方式。然而，该快捷方式存在缺陷。它未遵循 PG_lru 的使用约定，并且存在更严重的问题。
不可回收的 folios 并未链接在 lists[LRU_UNEVICTABLE] 上，因此 folio->lru 可被重用以保存 folio->mlock_count（参见 lruvec_init() 中的注释）。因此，lruvec_add_folio() 会跳过对这些 folios 执行 list_add()；其他所有将 folio 标记为不可回收的地方都会显式初始化 mlock_count：lru_add() 将其设置为 0，__mlock_folio() 和 __mlock_new_folio() 将其设置为 !!folio_test_mlocked(folio)。而 sort_folio() 未设置任何值，且其上方的 lru_gen_del_folio() 可能已通过 list_del() 污染了 folio->lru，导致 mlock_count 最终与 LIST_POISON2（读作 0x122，即 290）发生别名重叠。这一结果对用户可见：在 munlock 操作中，__munlock_folio() 会递减该虚假计数值，发现其仍非零后便退出执行，而未清除 PG_mlocked 标志，导致 folio 保持不可回收状态，且 Mlocked 会计统计信息持续虚高，直到该 folio 被释放为止。
此外，该快捷方式还以错误的顺序操作 LRU 标志。它在 PG_lru 仍设置的情况下调用 lru_gen_del_folio()，因此并发的 folio_test_clear_lru()（例如 compaction、folio_isolate_lru()）可能会在已从生成列表中移除的 folio 上成功执行，从而导致意外行为。
因此，通过将其作为普通 folios 进行隔离，并由通用收缩路径对其进行清理来修复此问题。这符合经典的 LRU 行为，并且对通用的换出或隔离行为不应产生可见影响。
此外也不存在性能顾虑：此类 folio 仅经过一次该流程处理，随后便永久脱离生成列表。
Be aware that VulDB is the high quality source for vulnerability data.