CVE-2026-90171 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
smb: smbdirect: освобождение ожидающих дочерних сокетов вне блокировки обработчика (handler lock)
Функция `smbdirect_socket_destroy()` освобождает ожидающие/готовые к использованию дочерние сокеты слушателя, сохраняя при этом захваченной блокировку обработчика (`&id_priv->handler_mutex`), полученную через `rdma_lock_handler()`, а не `sc->listen.lock`, и до вызова функции уничтожения самого идентификатора RDMA слушателя (`listener's rdma_destroy_id()`). Такой порядок действий имеет одно реальное последствие и одно косметическое.
Реальное последствие: функция `smbdirect_socket_release()` уменьшает последнее владение (reference) дочерним объектом, что приводит к уничтожению его идентификатора соединения (`cm_id`). Выполнение этого действия до вызова `rdma_destroy_id()` для слушателя позволяет функции `_cma_cancel_listens()`, запускаемой из контекста `_destroy_id()`, обращаться к уже освобожденному `id_priv` дочернего объекта. Это фиксируется KASAN как use-after-free (использование после освобождения) в подсистеме slab во время остановки слушателя:
[ 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]
[ 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
Косметическое последствие: освобождение дочернего объекта вызывает рекурсивный вызов `smbdirect_socket_destroy()`, который захватывает собственную блокировку обработчика (`rdma_lock_handler()`) дочернего объекта вложенно по отношению к блокировке слушателя. Идентификаторы соединения (cm_id) слушателя и дочернего элемента всегда являются разными экземплярами, поэтому реального взаимоблокирования (deadlock) возникнуть не может; ядро CM само вкладывает `handler_mutex` нового идентификатора подключения под `handler_mutex` слушающего идентификатора в функции `cma_ib_req_handler()`. Однако lockdep видит только один класс блокировок, сообщает о возможной рекурсивной блокировке и затем отключается, скрывая настоящие ошибки синхронизации на оставшееся время выполнения:
[ 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
Ожидающие/готовые дочерние элементы добавляются в локальный список под блокировкой `listen.lock` слушателя, пока захвачена блокировка обработчика (чтобы предотвратить добавление новых элементов через параллельный запрос CM CONNECT_REQUEST), но фактические вызовы `smbdirect_socket_release()` откладываются до момента уничтожения идентификатора cm_id слушателя и снятия его блокировки обработчика. Дочерние элементы являются независимыми сокетами, для завершения работы которых не требуются ни блокировка обработчика (`handler lock`) слушателя, ни его `cm_id`.
Уязвимость обнаружена с помощью инструмента ksmbdzzer [2], фаззера KSMBD, который использует libFuzzer с вектором покрытия на основе kcov-dataflow [1]: он объединяет значение операнда времени выполнения каждого проинструментированного сравнения/аргумента с его адресом возврата (PC) (по умолчанию для архитектуры ARM используется операция XOR: pc⊕val), так что новое значение операнда в известном месте считается новым покрытием.
[1] https://lwn.net/Articles/1077606/
[2] https://github.com/yskzalloc/kcov-dataflow
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.