CVE-2026-99254

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

io_uring: nie zalewaj zadania anulowania zadaniem task_work

io_ring_exit_work() pyta każde zadanie, które użyło pierścienia, o jego usunięcie
tctx według task_work i powtarza to, aż lista będzie pusta.
io_tctx_exit_cb() nie dotyka węzła, gdy zadanie jest realizowane
io_uring_cancel_generic(), która usuwa wszystkie węzły na jej końcu. Więc
element roboczy ponownie umieszcza wywołanie zwrotne w kolejce zaraz po jego zakończeniu, np
nic.

To więcej niż strata czasu. task_work_run() zwraca tylko wtedy, gdy jest to możliwe
znajdzie listę pustą. Jeśli pierścienie zostaną zwolnione z wnętrza
anulowanie, ponieważ prośby innych pierścieni zawierały ostatnie wzmianki
swoje pliki, aż do 64 elementów pracy wysyła wywołania zwrotne do jednego zadania
która nimi kieruje. Nigdy nie znajdzie pustej listy i nigdy do niej nie wróci
anulowania, węzły pozostają i tak dalej: zadanie z 60 parami
pierścieni, które odpytują się nawzajem, wykonało 280 000 wywołań zwrotnych w ciągu 5 sekund, 20
sekundy po exit_group(). Kończy się, gdy wszyscy nadawcy spóźniają się
w tym samym czasie. Do tego czasu zadanie utrzymuje procesor i elementy pracy zajęte.

W międzyczasie nie można zakończyć kończącego się zadania. execve() anuluje żądania
w ten sam sposób, więc aktywne zadanie również może utknąć tam na kilka minut. Jeśli
potrzeba więcej niż pięciu, elementy pracy trafiają do
WARN_ON_ONCE(time_after(jiffies, timeout)) io_ring_exit_work(). Nie
do tego potrzebne są przywileje.

Jeśli wywołanie zwrotne spełniło zadanie w trakcie anulowania, poczekaj chwilę, zanim to nastąpi
wysłane ponownie. W tym celu nikt nie musi budzić elementu roboczego: ani węzła
do tego czasu już nie będzie, albo nadejdzie kolej następnej rundy.