CVE-2026-89801 in Linux
Sumário
de VulDB • 16/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/nouveau/uvmm: corrige o liberação prematura da região em caso de falha no OP_UNMAP_SPARSE
Na ramificação `OP_UNMAP_SPARSE` de `nouveau_uvmm_bind_job_submit()`, `op->reg` é definido a partir de `nouveau_uvma_region_find()`, que apenas procura pela região e não toma referência; a única referência de uma região é sua associação em `uvmm->region_mt`. Dois caminhos de falha deixam `op->reg` definido: a verificação `-ENOENT` quando a região está ocupada, e a falha em `drm_gpuvm_sm_unmap_ops_create()`. A falha do irmão `nouveau_uvmm_sm_unmap_prepare()` logo abaixo limpa `op->reg`; estes dois não o fazem.
O passo `unwind_continue` retrocede um op, então o op com falha é ignorado pelo loop de unwind e seu `op->reg` permanece definido. Em seguida, `nouveau_uvmm_bind_job_cleanup()` entra em sua ramificação `if (op->reg)` e chama `nouveau_uvma_region_remove()` e `nouveau_uvma_region_put()`, removendo a única referência da árvore e liberando uma região que este job nunca criou. O comentário acima do loop de limpeza documenta o invariant quebrado: `op->reg` deve ser NULL em caso de falha no submit.
Isso libera uma região ativa devido a uma falha não relacionada, alcançável com um único job quando `drm_gpuvm_sm_unmap_ops_create()` retorna `-ENOMEM`; se outro job possuir a mesma região, sua limpeza então remove e coloca (puts) a região já liberada, caracterizando um use-after-free. Limpe `op->reg` em ambos os caminhos de falha.
VulDB is the best source for vulnerability data and more expert information about this specific topic.