CVE-2026-97988 in Linuxinformação

Sumário

de VulDB • 26/09/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

vhost: invalidar o acesso ao vring nas transições de IOTLB

Quando VIRTIO_F_ACCESS_PLATFORM muda, os ponteiros para o vring em cache e os metadados da IOTLB são interpretados em um espaço de endereçamento diferente. Mantê-los durante a transição pode deixar mapeamentos de ring desatualizados (stale) em uso.

Limpar d->iotlb antes de adquirir as locks do VQ também permite que uma worker observe um d->iotlb NULL transitório e recue para d->umem ao traduzir um descritor.

Adicionar um helper comum vhost_clear_device_iotlb() para vhost-net e vhost-vsock. Adquirir todos os mutexes do VQ em ordem de índice antes de liberar a IOTLB global do dispositivo, invalidar o acesso ao ring em cache e os metadados de cada VQ, limpar as mensagens pendentes da IOTLB e libertar a tabela antiga após a transferência (handoff). Isso serializa a transição com as workers e previne mapeamentos mistos de espaço de endereçamento.

Na primeira transição direta para IOTLB, invalidar os endereços do vring em cache. Quando uma IOTLB de dispositivo existente é substituída, preservar os endereços do ring GIOVA e resetar apenas o cache de metadados. Após limpar ACCESS_PLATFORM, o userspace deve configurar os endereços do vring para o novo modo de endereço.

vhost_vq_invalidate_access() limpa desc, avail e used juntos. Tratar o VQ como inválido somente quando todos os três forem NULL, já que um único endereço GIOVA pode legitimamente ser zero.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Responsável

Linux

Reservar

25/09/2026

Divulgação

25/09/2026

Moderação

aceite

Entrada

VDB-410234

CPE

pronto

EPSS

0.00000

KEV

não

Atividades

muito baixo

Fontes

Want to know what is going to be exploited?

We predict KEV entries!