CVE-2026-98360

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

RDMA/rxe: wstaw mcg do mcg_tree dopiero po pomyślnym wykonaniu funkcji rxe_mcast_add()

rxe_get_mcg() publikuje nowo przydzieloną grupę multiemisji w
rxe->mcg_tree przed zaprogramowaniem zapasowego adresu multiemisji Ethernet
z rxe_mcast_add(), która działa poza mcg_lock. Lokalna przestrzeń użytkownika
Klient RDMA osiąga tę ścieżkę z ATTACH_MCAST na UD QP; jeśli
rxe_mcast_add() następnie zwraca błąd (na przykład -ENODEV, gdy
wsparcie netdev zostało usunięte lub wystąpił błąd dev_mc_add()),
rozwinięcie zwalnia opublikowaną grupę bez usuwania jej z drzewa.
Późniejsze wyszukiwanie tego samego MGID powoduje wyłuskanie zwolnionej struktury rxe_mcg
z __rxe_lookup_mcg().

Napraw to, zachowując prywatność nowego mcg do czasu pomyślnego wykonania funkcji rxe_mcast_add().
Podziel publikację drzewa na __rxe_publish_mcg(), wywołaj rxe_mcast_add()
przed pobraniem odniesienia do drzewa i uwolnij wciąż prywatne mcg
porażka. Ponieważ grupa nigdy nie jest widoczna w mcg_tree, dopóki
adres multiemisji jest zaprogramowany, żaden współbieżny rozmówca nie może go sprawdzić ani
dołącz QP do grupy, która ma zostać rozebrana, więc ścieżka błędu
nie wymaga warunkowego odprężenia. Jeśli inny rozmówca opublikuje ten sam MGID
podczas programowania adresu należy ponownie sprawdzić po dodaniu
mcg_lock znajduje zwycięzcę; następnie ten obiekt wywołujący upuszcza swój prywatny obiekt i
równoważy własną rxe_mcast_add() z rxe_mcast_del() przed powrotem
zwycięzca.

Odtworzone przez wymuszenie zwrotu błędu rxe_mcast_add() w KASAN:
bez zmiany kolejne dołączenie do tego samego raportu MGID a
płyta-użyj-po-wolnej w __rxe_lookup_mcg(); wraz z nim wymuszona porażka
wraca czysto. Regresja przyłączania/odłączania bez wstrzykiwania, obejmująca:
wspólne łączenie/opuszczanie i ponowne podłączanie dwóch QP, pozostaje KASAN i jest czyste.