CVE-2026-89507

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

RDMA/UCMA: Zablokuj moduł obsługi w ucma_write_cm_event()

ctx->file można zmieniać tylko pod blokadą modułu obsługi i blokadą xa_lock, która
to jest to, co powstrzymuje zdarzenia uevents od kolejkowania dla ctx podczas ruchu ucma_migrate_id()
go do innego pliku. Rdzeń CM przejmuje tę blokadę przed wywołaniem
ucma_event_handler(), ale ścieżki write(), które same umieszczają w kolejce zdarzenia
nie.

ucma_write_cm_event() ponownie odczytuje plik ctx-> dla każdego z czterech dereferencji,
więc ucma_migrate_id() może zamienić go w połowie sekwencji:

mutex_lock(&ctx->plik->mut); /* plik A */
list_add_tail(&uevent->lista, &ctx->file->event_list); /* plik B */
mutex_unlock(&ctx->plik->mut); /* plik B */
wake_up_interruptible(&ctx->plik->poll_wait); /* plik B */

Okno jest samą funkcją mutex_lock(): piszący w nim śpi, podczas gdy
migracja ponownie przypisuje plik ctx->. Następnie list_add_tail() działa na plikach B
lista_zdarzeń zawierająca tylko muteks pliku A:

list_add korupcja. prev->next powinien być następny (ffff888101320f30),
ale było ffff88814a08c418. (poprzedni=ffff88814a075c18).
BŁĄD jądra w lib/list_debug.c:32!
Zadzwoń do śledzenia:
ucma_write_cm_event+0x36e/0x5e0

a mut pliku A pozostaje przechowywany na zawsze, blokując następnego zapisującego w stanie D.
Zdarzenie uevent również znajduje się na liście. Funkcja ucma_cleanup_ctx_events() nie będzie
chodzić, więc wykracza poza swój kontekst. /dev/infiniband/rdma_cm to 0666 i nie
W grę wchodzi urządzenie RDMA, więc nieuprzywilejowany użytkownik może to wszystko osiągnąć.

Weź blokadę modułu obsługi, tak jak robi to ucma_cleanup_mc_events(); ctx->cm_id to
przypięty przez odniesienie ucma_get_ctx().