CVE-2026-98507

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

mm/rmap: naprawiono brakującą barierę pomiędzy inicjowaniem anon_vma i publikowaniem vma->anon_vma

Na serwerze arm64 stwierdzamy, że zadanie próbuje przechwycić blokadę anon_vma
uruchamia zawieszone zadanie.

INFO: zadanie main:2354726 zablokowane na dłużej niż 120 sekund.
Skażony: G E 5.10.0-0021.aarch64 #1
„echo 0 > /proc/sys/kernel/hung_task_timeout_secs” wyłącza ten komunikat.
zadanie: stan główny: D stos: 0 pid: 2354726 ppid: 2350673 flagi: 0x00000a01
Śledzenie połączeń:
__przełącznik_na+0x7c/0xbc
__harmonogram+0x3b4/0x8a0
harmonogram+0x50/0xe0
rwsem_down_write_slowpath+0x3cc/0x6cc
down_write+0x60/0x260
__anon_vma_prepare+0x6c/0x210
do_anonymous_page+0x258/0x660
handle_pte_fault+0x188/0x214
__handle_mm_fault+0x1b0/0x380
uchwyt_mm_fault+0xf4/0x284
do_page_fault+0x19c/0x494
do_translation_fault+0xcc/0xf8
do_mem_abort+0x48/0xac
el0_da+0x44/0x80
el0_sync_handler+0x88/0xb4
el0_sync+0x160/0x180

Po przeanalizowaniu vmcore odkryliśmy, że anon_vma->root->rwsem.count to
-1. Istnieje inna anon_vma, której anon_vma->root->rwsem.count wynosi 1,
anon_vma->root->rwsem.owner pokazuje, że blokada jest wstrzymana, ale stos plików
task pokazuje, że zadanie nie posiada blokady anon_vma.

Po dodaniu większej liczby informacji dotyczących debugowania znaleźliśmy ponowne użycie funkcji __anon_vma_prepare().
anon_vma i uruchamia UAF anon_vma->root z powodu braku pamięci
bariera, prowadząca do zablokowania i odblokowania dwóch różnych anon_vma->root,
co prowadzi do anon_vma, która nigdy nie zostanie odblokowana, a kolejna anon_vma
nie dało się już zamknąć.

Ten wyścig wymaga dwóch sąsiednich VMA, które nie są połączone, ale są
kompatybilne z anon_vma (np. różnią się VMA_ACCESS_FLAGS, które można
zmienione przez mprotect()). Na każdym VMA występują jednocześnie błędy dwóch wątków, oba
wywołanie __anon_vma_prepare() z pozostawionym do odczytu tylko mmap_lock.

NICIĆ NICI B
__anon_vma_prepare __anon_vma_prepare
find_mergeable_anon_vma() -> NULL
anon_vma = anon_vma_alloc();
anon_vma->root = anon_vma;
// można zmienić kolejność obu sklepów
vma->anon_vma = anon_vma;
// znajduje anon_vma A
anon_vma = find_mergeable_anon_vma(vma);
anon_vma_lock_write(anon_vma);
// może nadal widzieć stary katalog główny
down_write(&anon_vma->root->rwsem);
anon_vma_unlock_write(anon_vma);
// zobacz nowy katalog główny, nigdy nie odblokowuj starego
up_write(&anon_vma->root->rwsem);

wątek A wyzwala błąd strony i wywołuje funkcję __anon_vma_prepare() w celu przygotowania
anon_vma dla powodującego błąd vma. __anon_vma_prepare() przydziela i
inicjuje nowy plik anon_vma, a następnie publikuje go w pliku vma za pomocą pliku zwykły
sklep. anon_vma_prepare() wymaga jedynie trzymania mmap_lock
odczyt, więc dwa wątki mogą jednocześnie powodować błędy w sąsiednich VMA.
Podczas gdy wątek A publikuje nowy plik anon_vma, wątek B może znaleźć plik anon_vma
poprzez find_mergeable_anon_vma(), a następnie blokuje anon_vma->root->rwsem.

Sklep do anon_vma->root w anon_vma_alloc() i sklep do
można zmienić kolejność vma->anon_vma. Funkcje anon_vma_lock_write() i spin_lock()
zapewniają jedynie semantykę nabycia, która nie uniemożliwia wcześniejszych sklepów
po nich ponownie uporządkowane. Semantyka wydania odpowiedniego
spin_unlock() i anon_vma_unlock_write() przychodzą za późno, sklep musi
vma->anon_vma zostało już opublikowane, zanim zaczną obowiązywać. W rezultacie
wątek B może zachować następującą kolejność:

vma->anon_vma = anon_vma;
anon_vma->root = anon_vma;

Płyta anon_vma to SLAB_TYPESAFE_BY_RCU, więc nowo przydzielona płyta anon_vma
może ponownie wykorzystać pamięć z wcześniej zwolnionej. Konstruktor
(anon_vma_ctor) nie resetuje anon_vma->root i __put_anon_vma()
również tego nie usuwa, więc stara wartość główna pozostaje aż do
anon_vma_alloc() zastępuje to. Jeśli ten sklep nie jest v
---obcięty---