CVE-2026-89757

W jądrze Linuksa usunięto następującą lukę:

mm/mglru: napraw i usuń zbędną obsługę folio

sort_folio() ma skrót do przenoszenia folio, których nie można już eksmitować
ale nadal znajdują się na liście pokoleń. Jednak ten skrót jest
buggy. Nie jest zgodny z konwencją użycia PG_lru i ma więcej
poważny problem.

Folio, których nie da się uniknąć, nie są wątkowane na listach [LRU_UNEVICTABLE], więc
folio->lru można ponownie wykorzystać do przechowywania folio->mlock_count (zobacz komentarz w
lruvec_init()). Dlatego lruvec_add_folio() pomija dla nich funkcję list_add(),
i każde inne miejsce, które powoduje, że folio jest nieuniknione, inicjuje się
mlock_count jawnie: lru_add() ustawia go na 0, __mlock_folio() i
__mlock_new_folio() ustaw na !!folio_test_mlocked(folio). sort_folio()
niczego nie ustawia, a lru_gen_del_folio() tuż nad nim mogła już to zrobić
zatrute folio->lru poprzez list_del(), więc mlock_count kończy się aliasowaniem
LIST_POISON2, co odczytuje się jako 0x122, tj. 290. Wynikiem jest użytkownik
widoczne. W przypadku Munlocka funkcja __munlock_folio() zmniejsza tę fałszywą liczbę
nadal jest niezerowy i kończy się przed wyczyszczeniem PG_mlocked, więc folio
pozostaje nieuniknione, a rachunkowość Mlocked pozostaje zawyżona do dnia
folio jest zwolnione.

Skrót dotyka również flag LRU w niewłaściwej kolejności. To dzwoni
lru_gen_del_folio(), podczas gdy PG_lru jest nadal ustawione, więc współbieżne
folio_test_clear_lru() (np. zagęszczanie, folio_isolate_lru()) może się powieść
na folio, które zostało już usunięte z listy generacji, co może
prowadzić do nieoczekiwanego zachowania.

Więc napraw to, izolując je jako zwykłe folio i pozwalając na ogólne
zmniejsz ścieżkę, wybij ich. Odpowiada to klasycznemu zachowaniu LRU i tam
nie powinno mieć widocznego wpływu na ogólne zachowanie związane z eksmisją lub izolacją.

Nie ma też żadnych problemów z wydajnością, takie folio przechodzi przez to
raz, a potem na dobre znika z list generacji.