CVE-2026-90171 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
smb: smbdirect: liberar sockets filhos pendentes fora da trava do manipulador (handler lock)
O smb_direct_socket_destroy() libera os sockets filhos pendentes/prontos do ouvinte enquanto ainda mantém a trava do manipulador do ouvinte, ou seja, o &id_priv->handler_mutex adquirido via rdma_lock_handler(), e não sc->listen.lock, e antes da própria destruição do id rdma do ouvinte (rdma_destroy_id()). Essa ordem tem uma consequência real e outra cosmética.
A consequência real: smbdirect_socket_release() remove a última referência ao filho, o que destrói o cm_id do filho. Fazer isso antes de chamar rdma_destroy_id() no ouvlete permite que _cma_cancel_listens(), executado durante a chamada da função _destroy_id do ouvinte, percorra um id_priv já liberado (freed), o qual é detectado pelo KASAN como um uso após liberação (use-after-free) em slab durante o desligamento do ouvinte:
[ 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
A consequência cosmética: liberar um filho recorre para dentro de smb_direct_socket_destroy(), que adquire a própria trava rdma_lock_handler() do filho, aninhada sob a do ouvinte. Os cm_ids do ouvinte e do filho são sempre instâncias diferentes, portanto isso não pode causar deadlock real; o próprio núcleo CM (Connection Manager) faz um novo aninhamento da handler_mutex de uma nova conexão id sob a do id em escuta em cma_ib_req_handler(). No entanto, o lockdep vê apenas uma classe de trava, relata possível bloqueio recursivo e, em seguida, desativa-se, ocultando bugs reais de bloqueio pelo restante da execução:
[ 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
Anexe os filhos pendentes/prontos a uma lista local sob a listen.lock do ouvinte, enquanto a trava do manipulador (handler lock) está mantida para que um CM CONNECT_REQUEST concorrente não possa adicionar mais elementos, mas adie as chamadas reais de smb_direct_socket_release() até depois da destruição do cm_id do ouvinte e do lançamento de sua handler lock. Os filhos são sockets independentes cuja desmontagem (teardown) não necessita nem da handler lock do ouvinte nem de seu cm_id.
Encontrado com ksmbdzzer [2], um fuzzer KSMBD que utiliza libFuzzer com um vetor de cobertura kcov-dataflow [1]: ele combina o valor operacional em tempo real de cada comparação/argumento instrumentado junto com sua PC (a configuração padrão do ARM os mistura como pc⊕val), de modo que um novo valor operando em um local conhecido conta como nova cobertura.
[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.