CVE-2026-80789 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
nvmet-tcp: limitar o comprimento dos dados SGL antes de alocar buffers de comando
nvmet_tcp_map_data() lê sgl->length (32 bits controlado pelo host) e, para o descritor de offset em-capsule (tipo 0x01), verifica-o contra port->inline_data_size antes do uso. Qualquer outro tipo de descritor SGL -- incluindo o descritor de bloco de dados SGL de transporte não-inline (tipo NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, que é o tipo usado por um host real para gravações fora do capsule) -- ignora completamente essa verificação e prossegue diretamente para:
cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt);
com len obtido diretamente da rede, sem limites superiores até 4 GiB.
nvmet_req_init() apenas analisa o comando e nunca inspeciona sgl->length, e nvmet_check_transfer_len() -- o único outro local onde transfer_len é validado -- executa mais tarde, a partir de req->execute(), após a alocação já ter ocorrido. Para um comando de gravação, o alvo responde com R2T e coloca o comando em espera aguardando que o host envie os dados; se o host (ou um peer não autenticado que simplesmente nunca dá continuidade) nunca enviar, o buffer sgl_alloc() permanece residente durante toda a vida do comando. NVMe/TCP não possui autenticação obrigatória na configuração padrão, portanto qualquer peer capaz de alcançar o portal alvo e concluir uma conexão Fabrics pode explorar isso com um único comando manipulado ad hoc, repetível entre filas e conexões para amplificação. Esta é uma alocação descontrolada de memória do kernel acionada por um peer remoto efetivamente não autenticado.
Validar len contra a mesma teto NVMET_TCP_MAXH2CDATA que este arquivo já usa para limitar os dados H2C por PDU, para cada tipo de descritor SGL, antes de realizar qualquer alocação. Isso fecha a brecha para o descritor não-inline enquanto mantém a verificação existente e mais restritiva inline_data_size no caso em-capsule.
Verificado em tempo de execução em um stand KASAN v6.19: com essa limitação aplicada, um comando de gravação manipulado ad hoc carregando um comprimento SGL não-inline excessivo é rejeitado antes que sgl_alloc() seja executado, onde o mesmo request anteriormente acionou uma alocação descontrolada do kernel de ~256 MiB (até 4 GiB) que permaneceu residente aguardando um R2T que o host nunca satisfaz.
If you want to get best quality of vulnerability data, you may have to visit VulDB.