Odebrany

CVE-2026-98068

opublikowano: 25.09.2026, 13:17

modyfikacja: 25.09.2026, 13:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

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

net/rds: nie pozwól, aby funkcja rds_conn_shutdown() zużywała równoczesny spadek

rds_conn_shutdown() kończy się przeniesieniem ścieżki z
RDS_CONN_DISCONNECTING do RDS_CONN_DOWN i również akceptuje
RDS_CONN_ERROR jako stan początkowy tego końcowego przejścia, tak że
FIN przetwarzany w kontekście Softirq podczas porzucania nie ulega wykolejeniu
zamknięcie na zaszumioną ścieżkę błędów.

Ale zużycie tego RDS_CONN_ERROR zużywa również przepustkę zamykającą
przyszedł z tym: rds_conn_path_drop() ustawia RDS_CONN_ERROR, a następnie ustawia się w kolejce
cp_down_w i przepustka rozpoczynająca się na ścieżce już w RDS_CONN_DOWN
jest niewykonalne. W przypadku obudowy FIN, która jest nieszkodliwa - gniazdo FIN
przybyło to samo gniazdo, które właśnie zwolniło. Tak nie jest
nieszkodliwe dla droppera, który najpierw przyczepił coś do ścieżki.

rds_tcp_accept_one() jest takim dropperem. Jego ścieżka żąda w
rds_tcp_accept_one_path() przejścia RDS_CONN_DOWN ->
RDS_CONN_CONNECTING i jednoczesny spadek - FIN na poprzednim
gniazdo w kontekście softirq, reset administracyjny - może umieścić ścieżkę
do RDS_CONN_ERROR pomiędzy tym roszczeniem a sprawdzeniem stanu
następuje, co akceptuje RDS_CONN_ERROR. Akceptacja następnie instaluje
świeżo zaakceptowane gniazdo z funkcją rds_tcp_set_callbacks() w kolejce
Teredown - który samplował tc->t_sock zanim istniało to gniazdo - jest
nadal działa. rds_connect_path_complete() nie może przejść do
RDS_CONN_UP i ponownie upuszcza ścieżkę, ustawiając w kolejce przepustkę, która powinna
zbierz gniazdo, które właśnie zainstalowało. Jeśli przerwa w locie będzie ostateczna
przejście zużywa RDS_CONN_ERROR tej kropli, znaleziony w kolejce przebieg
ścieżkę w RDS_CONN_DOWN i nic nie robi. Zainstalowane gniazdo jest
nigdy nie zburzony: stoi na stałym miejscu, z uzbrojonymi wywołaniami zwrotnymi i jego
rds_tcp_connection na rds_tcp_tc_list, peer widzi połączenie, które
nic nigdy nie jest czytane, a ścieżka jest zaklinowana w RDS_CONN_DOWN, aż do pewnego momentu
późniejsze wydarzenie ponownie go upuści. Reprodukowane z poszerzonymi oknami wyścigowymi jako
stale rosnąca kolejka odbiorcza na gnieździe należącym do utkniętej ścieżki
RDS_CONN_DOWN, ze ścieżką nadawczą partnera zaklinowaną za nią.

Wykonaj tylko ostatnie przejście ROZŁĄCZENIE -> W DÓŁ. Jeśli się nie powiedzie
ponieważ ścieżka znajduje się w RDS_CONN_ERROR, kropla przyspieszyła porzucenie:
anuluj licznik ponownego połączenia i wyczyść RDS_RECONNECT_PENDING - ten
kawałek pominiętego ogona, którego nie wolno zostawiać – i wrócić,
pozwolić przejść kolejce zrzutów, zakończyć zadanie: niszczy
wszystko, co w międzyczasie zostało dołączone do ścieżki, kończy
przejście do RDS_CONN_DOWN i ponowne uzbrojenie ponownego połączenia z własnego
ogon.

Wyciszenie timera w tej gałęzi ma znaczenie, ponieważ ma to znaczenie spadek wyścigowy
nie zawsze kolejka przechodzi: rds_conn_path_drop() zwraca bez
czekanie w kolejce, gdy oczekuje się zniszczenia - dokładnie taka sytuacja podczas a
porzucenie netns lub rozładowanie modułu, gdy FIN na umierającym gnieździe jest
przetwarzane, podczas gdy rds_conn_path_destroy() opróżnia cp_down_w. Jeśli
przepustka spłukiwana to ta, która przyjmuje ten powrót, nie istnieje żadna późniejsza przepustka,
i rds_conn_path_destroy() stwierdzi, że cp_conn_w jest nadal uzbrojony
(WARN_ON), a następnie zwolnij ścieżkę, której licznik czasu ponownego połączenia może nadal działać.
Po anulowaniu w oddziale każde wyjście z przepustki zamykającej opuszcza
licznik czasu wyciszył się, niezależnie od tego, które przejście zakończy przejście.

Sprawa FIN poczyniła postępy, jedno przejście później i wciąż bez rezultatu
hałaśliwe rejestrowanie. Każdy inny stan zachowuje dzisiejszą funkcję rds_conn_path_error()
obsługa; żaden bieżący zapis stanu cp nie może opuścić ścieżki ROZŁĄCZAJĄCEJ
w czymkolwiek innym niż RDS_CONN_ERROR (każdy inny pisarz jest cmpxchg z
stan nierozłączający), więc ta gałąź ma charakter obronny.

Na jądrach bez poprzednich poprawek występuje to samo zagrożenie
spokój oparty na próbkach; poprawka obowiązuje tam jednakowo.

In the Linux kernel, the following vulnerability has been resolved:

net/rds: don't let rds_conn_shutdown() consume a concurrent drop

rds_conn_shutdown() finishes by moving the path from
RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts
RDS_CONN_ERROR as the starting state of that final transition, so that
a FIN processed in softirq context during the teardown does not derail
the shutdown into a noisy error path.

But consuming that RDS_CONN_ERROR also consumes the shutdown pass that
came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues
cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN
is a no-op. For the FIN case that is harmless - the socket the FIN
arrived on is the very socket the teardown just released. It is not
harmless for a dropper that attached something to the path first.

rds_tcp_accept_one() is such a dropper. Its path claim in
rds_tcp_accept_one_path() transitions RDS_CONN_DOWN ->
RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous
socket in softirq context, an administrative reset - can put the path
into RDS_CONN_ERROR between that claim and the state check that
follows, which accepts RDS_CONN_ERROR. The accept then installs the
freshly accepted socket with rds_tcp_set_callbacks() while the queued
teardown - which sampled tc->t_sock before this socket existed - is
still running. rds_connect_path_complete() fails its transition to
RDS_CONN_UP and drops the path again, queueing the pass that should
reap the socket it just installed. If the in-flight shutdown's final
transition consumes that drop's RDS_CONN_ERROR, the queued pass finds
the path in RDS_CONN_DOWN and does nothing. The installed socket is
never torn down: it sits established with its callbacks armed and its
rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that
nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some
later event drops it again. Reproduced with widened race windows as
an ever-growing receive queue on a socket owned by a path stuck in
RDS_CONN_DOWN, with the peer's send path wedged behind it.

Make the final transition only DISCONNECTING -> DOWN. If it fails
because the path is in RDS_CONN_ERROR, a drop raced the teardown:
cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one
piece of the skipped tail that must not be left behind - and return,
letting the pass the drop queued finish the job: it tears down
whatever attached to the path in the meantime, completes the
transition to RDS_CONN_DOWN, and re-arms the reconnect from its own
tail.

The timer quiesce in that branch matters because the racing drop does
not always queue that pass: rds_conn_path_drop() returns without
queueing when a destroy is pending - exactly the situation during a
netns teardown or module unload, when a FIN on the dying socket is
processed while rds_conn_path_destroy() flushes cp_down_w. If the
flushed pass is the one that takes this return, no later pass exists,
and rds_conn_path_destroy() would find cp_conn_w still armed
(WARN_ON) and then free a path whose reconnect timer can still fire.
With the cancel in the branch, every exit of a shutdown pass leaves
the timer quiesced no matter which pass completes the transition.

The FIN case keeps making progress, one pass later and still without
noisy logging. Any other state keeps today's rds_conn_path_error()
handling; no current cp_state writer can leave a DISCONNECTING path
in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from
a non-DISCONNECTING state), so that branch is defensive.

On kernels without the preceding patches the same hazard exists with
the sample-based quiesce; the fix applies there equally.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve