CVE-2026-89791

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

perf: Naprawiono użycie po zwolnieniu, gdy odrodzenie perf mmap() przyspiesza z ostatnią munmap()

perf_mmap_close() usuwa rb->mmap_count *bez* trzymania
event->mmap_mutex (refcount_dec_and_test() tuż przed
refcount_dec_and_mutex_lock() zdarzenia->mmap_count). Równolegle
perf_mmap_rb() może umieścić całą swoją ścieżkę „odrodzenia” w tym oknie
(perf_mmap przechowuje event->mmap_mutex przez cały czas trwania, włączając
rb_alloc):

strona munmap (perf_mmap_close) strona mmap (perf_mmap_rb)
-------------------------------------------------- --------------------------------
rb->mmap_count 1 -> 0 (bez blokady) (wstrzymuje zdarzenie->mmap_mutex)
inc_not_zero(rb->mmap_count) kończy się niepowodzeniem
ring_buffer_attach(zdarzenie, NULL)
rb_alloc() + dołącz nowy rb
refcount_set(&event->mmap_count, 1)
zamek; zdarzenie->mmap_count 1 -> 0
ring_buffer_attach(zdarzenie, NULL)
ring_buffer_put() -> zwalnia *nowy* rb

refcount_set(&event->mmap_count, 1) odrodzenia jest niewidoczny
1 -> 1 napisz: zamknięcie zwalnia właśnie odnowiony bufor, chociaż
inny proces nadal go mapuje — użycie na poziomie strony po zwolnieniu
umożliwiając lokalną eskalację uprawnień do rootowania przez dowolnego nieuprzywilejowanego użytkownika
(domyślnie kernel.perf_event_paranoid=2).

Zamień kolejność dwóch aktualizacji liczników: event->mmap_count is
spadł jako pierwszy za pomocą refcount_dec_and_mutex_lock(), więc jest to 1 -> 0
przejście i ring_buffer_attach() pozostają serializowane
perf_mmap(). rb->mmap_count == 0 oznacza wówczas każde zdarzenie za pomocą
bufor jest już odłączony, więc wynik spadku rb->mmap_count
może bezpośrednio zamknąć pozostałe rozbicie, a detach_rest już nie jest
potrzebne.

Wprowadzono wcześniejszą poprawkę dla tego wyścigu od Kyle’a Zenga i Davida Lee
event->mmap_mutex wokół obu aktualizacji liczników [0]; tutaj nie-ostatni
zamknięcie pozostaje bez zamka.