Odebrany

CVE-2026-98070

opublikowano: 25.09.2026, 13:17

modyfikacja: 25.09.2026, 17:18

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: uzyskaj RDS_IN_XMIT w rds_tcp_reset_callbacks()

rds_tcp_reset_callbacks() wycisza ścieżkę transmisji poprzez ustawienie
stan ścieżki do RDS_CONN_RESETTING, a następnie czekam na RDS_IN_XMIT
należy pobrać czystą próbkę przed zamianą bazowego gniazda i wywołaniem
rds_send_path_reset().

Próbkowanie czystego bitu to nie to samo, co posiadanie go: rds_send_xmit()
może ponownie uzyskać RDS_IN_XMIT zaraz po powrocie funkcji Wait_event(). Jego
ponowne sprawdzenie stanu po zajęciu blokady jest wzorcem buforowania magazynu (the
resetter zapisuje stan i odczytuje bit, nadawca zapisuje
bit i odczytuje stan), a nabyć_in_xmit() jest tylko przejęciem
operacji, więc w słabo uporządkowanych architekturach obie strony mogą przegapić
wzajemne zapisy i ścieżka transmisji przebiegają jednocześnie
rds_send_path_reset() przepisując stan cp_xmit_* - czyli dokładnie
co powyższy komentarz rds_send_path_reset() mówi swoim rozmówcom
zapobiegać.

Zamiast tego weź zamek, przytrzymaj go nad gniazdem i
rds_send_path_reset() i zwolnij ją z wybudzeniem na końcu. The
ograniczenie kolejności blokad udokumentowane powyżej nadal obowiązuje: the
blokada jest pobierana przed lock_sock(), więc nadawca wewnątrz tcp_sendmsg()
Nigdy nie można czekać, dopóki trzymamy blokadę gniazda.

Dwie szczegóły starego kodu znikają wraz z tą samą zmianą:

- t_sock jest teraz odczytywany dopiero po uzyskaniu blokady. Stary kod
zapisz go w pamięci podręcznej przed czekaniem; porzucenie w rds_conn_shutdown()
zwalnia to gniazdo i czyści t_sock, więc wskaźnik był wcześniej buforowany
oczekiwanie może być nieaktualne do czasu wznowienia ścieżki akceptacji. Czytanie
znajduje się pod RDS_IN_XMIT, co powoduje, że wykluczenie jest kompletne, gdy
porzucenie posiada ten sam zamek, który organizuje następna łatka; aż
wtedy porzucenie nadal próbkuje tylko fragment i dwie ścieżki
pozostali tak samo wystawieni na siebie, jak dzisiaj.

- Stara wczesna ścieżka !osock o nazwie rds_send_path_reset() z nr
serializacja w ogóle. Teraz działa pod zamkiem jak zwykle
ścieżka. Warunkowe przejście RDS_CONN_RESETTING pliku
poprzednia łatka ma miejsce przed sprawdzeniem gniazda w obie strony: ścieżkę
znaleziony bez gniazda albo nadal się łączy (jego ponowne połączenie
worker zablokowany na t_conn_path_lock) i zgodnie z prawem przechodzi
RESETOWANIE -> UP na nowym gnieździe lub zostało ono rozebrane
w międzyczasie i zostaje usunięty.

Komentarz w funkcji opisujący stary wyciszenie oparte na oczekiwaniu to
przepisany, aby opisać komentarz oparty na blokadzie i nieaktualny komentarz do bloku
nad funkcją (która nadal opisuje wartość zwracaną i
niekompletna lista autorów t_sock) została odświeżona, aby wymienić wszystkich czterech
pisarze - ścieżki łączenia, akceptowania, niszczenia i wymiany - i co
serializuje każdy z nich.

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

net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()

rds_tcp_reset_callbacks() quiesces the transmit path by setting the
path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to
be sampled clear before swapping the underlying socket and calling
rds_send_path_reset().

Sampling the bit clear is not the same as owning it: rds_send_xmit()
can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its
state recheck after taking the lock is a store-buffering pattern (the
resetter writes the state and reads the bit, the sender writes the
bit and reads the state) and acquire_in_xmit() is only an acquire
operation, so on weakly ordered architectures both sides can miss
each other's write and the transmit path then runs concurrently with
rds_send_path_reset() rewriting cp_xmit_* state - which is exactly
what the comment above rds_send_path_reset() tells its callers to
prevent.

Take the lock instead, hold it across the socket swap and
rds_send_path_reset(), and release it with a wake-up at the end. The
lock-ordering constraint documented above the wait still holds: the
lock is acquired before lock_sock(), so a sender inside tcp_sendmsg()
can never be waited on while we hold the socket lock.

Two details of the old code go away with the same change:

- t_sock is now read only after the lock is acquired. The old code
cached it before waiting; the teardown in rds_conn_shutdown()
releases that socket and clears t_sock, so a pointer cached before
the wait can be stale by the time the accept path resumes. Reading
it under RDS_IN_XMIT is what makes the exclusion complete once the
teardown owns the same lock, which the next patch arranges; until
then the teardown still only samples the bit, and the two paths
remain as exposed to each other as they are today.

- The old !osock early path called rds_send_path_reset() with no
serialization at all. It now runs under the lock like the normal
path. The conditional RDS_CONN_RESETTING transition of the
previous patch happens before the socket check either way: a path
found without a socket is either still connecting (its reconnect
worker blocked on t_conn_path_lock) and legitimately goes
RESETTING -> UP on the new socket, or it has been torn down
meanwhile and is dropped.

The in-function comment describing the old wait-based quiesce is
rewritten to describe the lock-based one, and the stale block comment
above the function (which still described a return value and an
incomplete list of t_sock writers) is refreshed to name all four
writers - the connect, accept, teardown and swap paths - and what
serializes each of them.

>_ 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