Katalog CVE

CVE-2026-89791

WysokieCVSS 7.8
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.19%

Percentyl 9 - wyżej niż 9% wszystkich znanych CVE

Streszczenie

W jądrze Linux występuje podatność use-after-free w mechanizmie perf, gdy wywołanie perf mmap() (tzw. revival) ściga się z ostatnim munmap(). Funkcja perf_mmap_close() zmniejsza licznik rb->mmap_count bez trzymania event->mmap_mutex, co pozwala równoległemu perf_mmap_rb() na ponowne podpięcie bufora, który następnie zostaje zwolniony mimo że inny proces wciąż ma go zmapowanego.

Ocena ryzyka

Podatność pozwala lokalnemu, nieuprzywilejowanemu użytkownikowi na przeprowadzenie ataku use-after-free na poziomie stron pamięci, co może prowadzić do eskalacji uprawnień do konta root. Domyślna konfiguracja (kernel.perf_event_paranoid=2) nie chroni przed tym atakiem.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę, która zamienia kolejność aktualizacji liczników event->mmap_count i rb->mmap_count, zapewniając serializację z perf_mmap(). Jeśli aktualizacja nie jest możliwa, rozważ ograniczenie dostępu do perf_event poprzez zwiększenie wartości kernel.perf_event_paranoid.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS