CVE-2026-82425

Osiągalna asercja w Apache bRPC (wersja < 1.18.0) na wszystkich platformach umożliwia złośliwemu zdalnemu partnerowi zawieszenie procesu, co skutkuje odmową usługi.

Główna przyczyna:
Gdy gniazdo z włączoną funkcją sprawdzania stanu nie powiedzie się, Socket::WaitAndReset zamyka swój deskryptor pliku, podczas gdy program rozsyłający zdarzenia może nadal dostarczać zdarzenie wejściowe (EPOLLIN/EVFILT_READ), które zostało pobrane dla właśnie zamkniętego fd. Jeśli następnie sprawdzenie stanu zakończy się pomyślnie i wznowi działanie Socket, Socket::Address powiedzie się ponownie, podczas gdy fd nadal wynosi -1 (następny zapis ponownie łączy się na żądanie). W tym oknie Socket::OnInputEvent trafia CHECK(!(events & EPOLLIN)) (lub odpowiednik kqueue), ponieważ Socket jest adresowalny, ale nie ma fd. Błędy CHECK kończą proces, gdy bRPC jest zbudowane przy użyciu glog lub gdy włączona jest opcja gflag -crash_on_fatal_log (CHECK zawsze kończy się również w kompilacjach OFFICIAL_BUILD/NDEBUG).

Dotknięte scenariusze:
Aplikacje korzystające z klientów bRPC z włączoną kontrolą stanu (-health_check_interval). Złośliwy zdalny element równorzędny, z którym łączy się klient, może celowo przerwać połączenia i natychmiast zaakceptować próby sprawdzania stanu, przyspieszając przerwanie połączenia przed ponownym przywróceniem kontroli stanu, aby wyzwolić potwierdzenie i przerwać proces.

Jak naprawić:
(Wybierz jedną z poniższych opcji)
1. Zaktualizuj bRPC do wersji 1.18.0, która rozwiązuje ten problem.
2. Zastosuj tę poprawkę: https://github.com/apache/brpc/pull/3510

Uwaga:
Po zastosowaniu poprawki nieaktualne zdarzenia wejściowe w gnieździe przywróconym bez fd są dyskretnie usuwane zamiast wyzwalać potwierdzenie. Żaden interfejs widoczny dla użytkownika ani protokół przewodowy nie są zmieniane.