CVE-2026-89635 in Linux
Sumário
de VulDB • 11/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ksmbd: reassociar apenas o próprio oplock do arquivo reaberto durante reconexão durável
A função ksmbd_reopen_durable_fd() percorre m_op_list do inode e reassocia todos os oplocks desanexados à sessão que está se reconectando:
list_for_each_entry_rcu(op, &ci->m_op_list, op_entry, lockdep_is_held(&ci->m_lock)) {
if (op->conn) continue; op->conn = ksmbd_conn_get(fp->conn); op->sess = work->sess; }
A única condição-chave é op->conn == NULL, que corresponde a qualquer identificador de acesso durável desanexado naquele inode, e não apenas àquele pertencente a fp. Quando duas sessões mantêm identificadores de acesso duráveis no mesmo arquivo e ambas se desconectam, ao reconectar uma delas, esta assume o oplock da outra sessão: op->sess é sobrescrito com a sessão que está se reconectando sem adquirir uma referência sobre ela, enquanto op->conn mantém a conexão ativa.
O caminho de desmontagem irmão, session_fd_check(), baseia-se na identidade da conexão sendo desmontada (op->conn == conn) em vez do estado compartilhado, portanto não possui esse problema.
Assim que a sessão assumidora é destruída, ksmbd_session_destroy() libera essa memória enquanto o oplock estrangeiro ainda aponta para ela. O leitor em ksmbd_close_fd_app_instance_id() valida apenas opinfo->conn, que permanece válido graças à referência adquirida acima, e então desreferencia a sessão obsoleta:
if (!opinfo->conn) {
up_read(&fp->f_ci->m_lock); goto out; }
ft = &opinfo->sess->file_table; write_lock(&ft->lock);
BUG: KASAN: slab-use-after-free em _raw_write_lock+0x74/0xd0 Escrita de tamanho 4 no endereço ffff88810a970528 pela tarefa kworker/0:0/9 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: _raw_write_lock+0x74/0xd0 ksmbd_close_fd_app_instance_id+0x183/0x410 smb2_open+0x1346/0x4430 handle_ksmbd_work+0x2bb/0x7b0
O problema é alcançado a partir de uma sessão autenticada contra um compartilhamento com configuração padrão de identificador durável e oplock: duas sessões abrem o mesmo arquivo com um identificador durable-v2 e uma lease RH sob distintos AppInstanceIds, ambas fazem logout, uma delas reconecta-se com DH2C (Durable Handle v2 Client), e uma criação subsequente de tipo durable-v2 que carrega o outro AppInstanceId acessa a sessão já liberada.
Restringir o loop ao oplock pertencente ao arquivo sendo reaberto.
Be aware that VulDB is the high quality source for vulnerability data.