Odebrany

CVE-2026-90171

opublikowano: 17.09.2026, 19:17

modyfikacja: 17.09.2026, 19: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ę:

smb: smbdirect: zwolnij oczekujące gniazda podrzędne poza blokadą modułu obsługi

smbdirect_socket_destroy() zwalnia oczekujące/gotowe dziecko słuchacza
gniazd, wciąż trzymając blokadę modułu obsługi słuchacza,
&id_priv->handler_mutex pobrane przez rdma_lock_handler(), nie
sc->listen.lock, a przed własną funkcją rdma_destroy_id() słuchacza.
To uporządkowanie ma jedną realną konsekwencję i jedną kosmetyczną.

Prawdziwy: smbdirect_socket_release() upuszcza ostatnią funkcję dziecka
referencja, która niszczy cm_id dziecka. Robiąc to przed
rdma_destroy_id() słuchacza pozwala _cma_cancel_litens(), uruchamiając
_destroy_id(), słuchacza, idź już uwolnione dziecko id_priv,
które KASAN łapie jako blok-użycie-po-wolności podczas wyłączania słuchacza:

[ 4758.909130] BŁĄD: KASAN: użycie płyty po zwolnieniu w __mutex_lock+0x1469/0x1560
[4758.911450] Odczyt rozmiaru 1 pod adresem ffff88821c381db4 przez zadanie ksmbd.control/1652
[ 4758.913262] Śledzenie połączenia:
[ 4758.913267] <ZADANIE>
[ 4758.913299] __mutex_lock+0x1469/0x1560
[ 4758.913408] _cma_cancel_listens+0x312/0x3b0
[ 4758.913413] _destroy_id+0x363/0xee0
[ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440
[ 4758.913443] smbdirect_socket_release+0x124/0x230
[ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190
[ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0
[ 4758.913463] sklep_serwera_zabicia+0x1fb/0x2b0
[ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0
[ 4758.913507] vfs_write+0x5e7/0xc70
[ 4758.913528] ksys_write+0x12a/0x210
[ 4758.913541] do_syscall_64+0x135/0x460
[ 4758.913555] wpis_SYSCALL_64_after_hwframe+0x77/0x7f

Kosmetyczny: wypuszczenie dziecka powraca
smbdirect_socket_destroy(), która pobiera dane dziecka
blokada rdma_lock_handler() zagnieżdżona pod blokiem słuchacza. Słuchacza
i cm_id dziecka są zawsze różnymi instancjami, więc nie może
prawdziwy impas; sam rdzeń CM zagnieżdża nowe identyfikatory połączeń
handler_mutex pod identyfikatorami nasłuchiwania w cma_ib_req_handler(). Ale
lockdep widzi tylko jedną klasę blokady, zgłasza możliwe blokowanie rekurencyjne,
a następnie wyłącza się, ukrywając prawdziwe błędy blokowania przez resztę
biegnij:

[ 2424.579653] OSTRZEŻENIE: wykryto możliwe blokowanie rekurencyjne
[ 2424.581180] 7.1.0-next-20260623+ #89 Nieskażony
[ 2424.582548] ------------------------------------------------------
[2424.584500] ksmbd.control/8854 próbuje uzyskać blokadę:
[ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, pod adresem: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.590590]
[2424.590590], ale zadanie już blokuje:
[ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, pod adresem: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.594178]
[2424.594178] inne informacje, które mogą pomóc nam w debugowaniu tego:
[2424.596634] Możliwy niebezpieczny scenariusz blokowania:
[ 2424.596634]
[2424.598841] Procesor0
[ 2424.599765] ----
[2424.600695] lock(&id_priv->handler_mutex);
[2424.601836] lock(&id_priv->handler_mutex);
[ 2424.602590]
[ 2424.602590] *** ZAMKNIĘCIE ***
[ 2424.602590]
[2424.604512] Przyczyną może być brak zapisu zagnieżdżenia blokady

Połącz oczekujące/gotowe dzieci na listę lokalną pod
blokada słuchacza, podczas gdy blokada modułu obsługi jest utrzymywana jednocześnie
CM CONNECT_REQUEST nie może dodać więcej, ale odłożyć faktyczną
smbdirect_socket_release() wywołuje do czasu, aż cm_id słuchacza zostanie zakończone
został zniszczony, a zamek uchwytu opuszczony. Dzieci są
niezależne gniazda, których rozbiórka nie jest konieczna dla słuchacza
blokadę modułu obsługi ani jej cm_id.

Znaleziono wraz z ksmbdzzer [2], fuzzerem KSMBD, który steruje biblioteką libFuzzer za pomocą
wektor pokrycia kcov-dataflow [1]: składa każdy instrument
wartość operandu wykonania porównania/argumentu wraz z jego komputerem (
domyślne ramię miesza je jako pc⊕val), tak że nowa wartość operandu ma znaną wartość
miejsce liczy się jako nowe pokrycie.

[1] https://lwn.net/Articles/1077606/
[2] https://github.com/yskzalloc/kcov-dataflow

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

smb: smbdirect: release pending child sockets outside the handler lock

smbdirect_socket_destroy() releases the listener's pending/ready child
sockets while still holding the listener's handler lock, the
&id_priv->handler_mutex taken via rdma_lock_handler(), not
sc->listen.lock, and before the listener's own rdma_destroy_id().
That ordering has one real consequence and one cosmetic one.

The real one: smbdirect_socket_release() drops the child's last
reference, which destroys the child's cm_id. Doing that before the
listener's rdma_destroy_id() lets _cma_cancel_listens(), running from
the listener's _destroy_id(), walk an already freed child id_priv,
which KASAN catches as a slab-use-after-free during listener shutdown:

[ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469/0x1560
[ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652
[ 4758.913262] Call Trace:
[ 4758.913267] <TASK>
[ 4758.913299] __mutex_lock+0x1469/0x1560
[ 4758.913408] _cma_cancel_listens+0x312/0x3b0
[ 4758.913413] _destroy_id+0x363/0xee0
[ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440
[ 4758.913443] smbdirect_socket_release+0x124/0x230
[ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190
[ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0
[ 4758.913463] kill_server_store+0x1fb/0x2b0
[ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0
[ 4758.913507] vfs_write+0x5e7/0xc70
[ 4758.913528] ksys_write+0x12a/0x210
[ 4758.913541] do_syscall_64+0x135/0x460
[ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f

The cosmetic one: releasing a child recurses into
smbdirect_socket_destroy(), which takes the child's own
rdma_lock_handler() lock nested under the listener's. The listener's
and the child's cm_id are always different instances, so this cannot
deadlock for real; the CM core itself nests a new connection id's
handler_mutex under the listening id's in cma_ib_req_handler(). But
lockdep only sees one lock class, reports possible recursive locking,
and then disables itself, hiding real locking bugs for the rest of the
run:

[ 2424.579653] WARNING: possible recursive locking detected
[ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted
[ 2424.582548] --------------------------------------------
[ 2424.584500] ksmbd.control/8854 is trying to acquire lock:
[ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.590590]
[ 2424.590590] but task is already holding lock:
[ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.594178]
[ 2424.594178] other info that might help us debug this:
[ 2424.596634] Possible unsafe locking scenario:
[ 2424.596634]
[ 2424.598841] CPU0
[ 2424.599765] ----
[ 2424.600695] lock(&id_priv->handler_mutex);
[ 2424.601836] lock(&id_priv->handler_mutex);
[ 2424.602590]
[ 2424.602590] *** DEADLOCK ***
[ 2424.602590]
[ 2424.604512] May be due to missing lock nesting notation

Splice the pending/ready children onto a local list under the
listener's listen.lock, while the handler lock is held so a concurrent
CM CONNECT_REQUEST cannot add more, but defer the actual
smbdirect_socket_release() calls until after the listener's cm_id has
been destroyed and its handler lock dropped. The children are
independent sockets whose teardown needs neither the listener's
handler lock nor its cm_id.

Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a
kcov-dataflow [1] coverage vector: it folds each instrumented
comparison/argument's runtime operand value together with its PC (the
default arm mixes them as pc⊕val) so that a new operand value at a known
site counts as new coverage.

[1] https://lwn.net/Articles/1077606/
[2] https://github.com/yskzalloc/kcov-dataflow

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