CVE-2026-74580

Resumo

No kernel Linux, a seguinte vulnerabilidade foi resolvida: vhost: redefinir o cache de metadados do vring na reconfiguração do vring vq->meta_iotlb[] armazena em cache o vhost_iotlb_map que sustenta cada região de metadados do vring, e iotlb_access_ok() retorna antecipadamente em caso de acerto no cache, tomando o acerto como prova de que a região já foi validada: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; O cache é redefinido em VHOST_IOTLB_UPDATE e VHOST_IOTLB_INVALIDATE, na (re)inicialização do IOTLB do dispositivo e na redefinição do vq, mas não quando VHOST_SET_VRING_ADDR substitui vq->desc, vq->avail e vq->used, nem quando VHOST_SET_VRING_NUM altera os tamanhos das regiões. Com um IOTLB de dispositivo anexado, ambos os ioctls são aceitos enquanto o vq está ativo, e nenhum deles valida os endereços no momento do ioctl: vq_access_ok() e vq_log_used_access_ok() retornam true antecipadamente porque os endereços são GIOVAs, adiando a validação para o momento do prefetch. Uma vez que o cache tenha sido populado, essa validação adiada deixa de ser executada -- vq_meta_prefetch() encontra a entrada obsoleta e retorna true -- e vhost_vq_meta_fetch() continua traduzindo através do mapeamento antigo como map->addr + addr - map->start para um endereço que o mapeamento já não cobre. vhost_copy_to_user() e vhost_copy_from_user() consomem o resultado com __copy_to_user() e __copy_from_user(), que também não o verificam, pelo que uma atualização subsequente do used ring ou uma busca de descritor acede a memória fora da região que o IOTLB realmente mapeia. Redefina o cache de metadados sempre que o vring for reconfigurado, para que os novos endereços sejam encaminhados novamente pelo caminho lento de iotlb_access_ok().

Fontes

• security-researchPoC

  Código C de prova de conceito e writeups para vulnerabilidades divulgadas do kernel Linux, incluindo fontes de exploit por CVE e análise técnica.