Katalog CVE

CVE-2025-37747

ŚrednieCVSS 5.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.25%

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

Streszczenie

W jądrze Linux naprawiono błąd w podsystemie perf, który powodował zawieszenie podczas zwalniania zdarzenia sigtrap. Problem występował, gdy powiązany odroczony sygnał nie został wysłany przed zamknięciem pliku, co prowadziło do niepowodzenia anulowania zadania i oczekiwania w rcuwait_wait_event(). Poprawka polega na pobraniu referencji do zdarzenia przy kolejkowaniu zadania perf i zwolnieniu jej w zadaniu, z zachowaniem ostrożności przy zwalnianiu zdarzeń potomnych i nadrzędnych.

Ocena ryzyka

Podatność może prowadzić do zawieszenia procesów lub całego systemu podczas zamykania plików powiązanych ze zdarzeniami perf, co może być wykorzystane do przeprowadzenia ataku typu denial of service. Organizacje korzystające z podsystemu perf w jądrze Linux są narażone na zakłócenia działania.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2025-37747. Jeśli aktualizacja nie jest możliwa, rozważ ograniczenie dostępu do interfejsu perf_event_open dla nieuprzywilejowanych użytkowników.

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 hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job.

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