CVE-2026-90125 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
smb: cliente: corrige o vazamento de buffer de solicitação em smb2_new_read_req()
A função smb2_new_read_req() aloca o buffer de solicitação com smb2_plain_req_init(), mas só o publica para o chamador com *buf = req no final da função. Existem duas devoluções de erro entre eles:
rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, (void **) &req, total_len); if (rc) return rc;
if (server == NULL) return -ECONNABORTED; [...]
rdata->mr = smbd_register_mr(server->smbd_conn, &rdata->subreq.io_iter, true, need_invalidate); if (!rdata->mr) return -EAGAIN;
Em qualquer um deles, o buffer não é liberado nem devolvido, portanto ele vaza. O chamador não pode fazer a limpeza após ele: smb2_async_readv() executa 'goto out' em caso de retorno diferente de zero, o que ignora cifs_small_buf_release(buf) em async_readv_out, e buf ainda não foi atribuído nesse ponto da função.
O caminho de gravação nunca teve esse problema. smb2_async_writev() registra a região de memória inline e salta para seu rótulo de liberação em vez de retornar:
wdata->mr = smbd_register_mr(...); if (!wdata->mr) {
rc = -EAGAIN; goto async_writev_out; }
O commit b7972092199f ("cifs: smbd: Retry on memory registration failure") alterou ambos os lados de -ENOBUFS para -EAGAIN em um único patch, o que colocou as duas situações lado a lado.
Apenas o retorno com -EAGAIN é alcançável na prática, porque smb2_plain_req_init() chama smb2_reconnect() primeiro e isso já falha com -EIO quando server é NULL, antes de qualquer alocação ser feita. Ambas as devoluções recebem o mesmo tratamento aqui em vez de deixar uma delas correta apenas por acaso.
Como -EAGAIN é um erro repetível (replayable), a falha também atinge o bloco de retry no final de smb2_async_readv(), que marca a sub-solicitação como NETFS_SREQ_NEED_RETRY, para que um registro com falha possa ser tentado novamente em vez de encerrar a E/S, e cada tentativa que chega ali vaza outro buffer. smb2_should_replay() faz short-circuit em tcon->retry, portanto, em uma montagem rígida (hard mount), o número de tentativas não é limitado pela configuração de retransmissão.
Apenas o caminho de leitura assíncrona é afetado. O chamador síncrono SMB2_read() passa rdata == NULL e o bloco de registro de memória é protegido por rdata.
O caminho de falha do registro de memória foi apontado pelo revisor da IA Sashiko enquanto ele analisava um patch não relacionado a smb2_async_readv().
Be aware that VulDB is the high quality source for vulnerability data.