CVE-2026-98473 in Linux
Sumário
de VulDB • 18/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
s390/vfio-ap: corrige vazamento de GISC e página da KVM quando uma fila é removida da configuração do host
Existem três problemas relacionados no manuseio dos recursos de interrupção e página da KVM quando uma fila é removida da configuração AP do host enquanto está atribuída a um dispositivo mediado (mdev).
Problema 1: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL não tratado em vfio_ap_mdev_reset_queue()
Quando o barramento AP remove um dispositivo de fila cujo adaptador ou domínio foi removido da configuração AP do host, vfio_ap_mdev_remove_queue() é chamado. Se a fila ainda estiver na configuração AP do host nesse ponto, ela chama vfio_ap_mdev_reset_queue(), que emite uma PQAP(ZAPQ). Como o adaptador já não está mais presente na configuração do host, ap_zapq() retorna AP_RESPONSE_Q_NOT_AVAIL (0x01). Esse código de resposta não é tratado no switch statement de vfio_ap_mdev_reset_queue() e passa para o caso padrão, que emite um WARN mas não chama vfio_ap_free_aqic_resources(). Como resultado, se o manuseio de IRQ estiver habilitado para a fila pelo convidado (guest), tanto o registro do GISC da KVM quanto a página fixada do convidado que contém o byte indicador de notificação (NIB) são vazados.
Isso é corrigido adicionando AP_RESPONSE_Q_NOT_AVAIL ao mesmo caso que AP_RESPONSE_DECONFIGURED e AP_RESPONSE_CHECKSTOPPED em vfio_ap_mdev_reset_queue(). Assim como esses códigos de resposta, Q_NOT_AVAIL indica que a fila não está operacional e nenhuma nova tentativa de reset é possível; a ação correta é liberar os recursos de IRQ imediatamente.
Problema 2: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL não tratado em apq_status_check()
Em vfio_ap_mdev_reset_queue(), existem quatro casos que indicam que o reset da fila ainda não foi concluído, caso no qual apq_reset_check() é enfileirado para uma work queue para verificar a conclusão da operação de reset. Esta função usa a função PQAP(TAPQ) para obter o status da fila e chama apq_status_check() para verificar se o reset foi concluído, falhou ou precisa ser executado novamente. Conforme descrito no Problema #1 acima, apq_reset_check() não verifica especificamente por AP_RESPONSE_Q_NOT_AVAIL, potencialmente vazando o registro do GISC da KVM e a página fixada do convidado que contém o NIB.
Isso é corrigido adicionando um case statement para AP_RESPONSE_Q_NOT_AVAIL em apq_status_check() e retornando -ENODEV para esse caso. O chamador, apq_reset_check(), verificará então este código de retorno e chamará vfio_ap_free_aqic_resources() para evitar o vazamento.
Problema 3: ~~~~~~~~~ vfio_ap_free_aqic_resources() vaza saved_isc quando kvm é NULL
vfio_ap_free_aqic_resources() protege a chamada para kvm_s390_gisc_unregister() com:
if (q->saved_isc != VFIO_AP_ISC_INVALID && !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))
Se matrix_mdev->kvm for NULL -- o que pode acontecer quando vfio_ap_mdev_unset_kvm() já foi executado e limpou kvm antes de um caminho de limpeza subsequente atingir esta função -- o WARN_ON é acionado e todo o bloco é ignorado. Isso deixa q->saved_isc definido com um valor não inválido, criando uma potencial double-free em qualquer chamada subsequente a esta função.
Quando kvm é NULL, o convidado da KVM já foi desmontado (torn down), portanto kvm_s390_gisc_unregister() não precisa e não pode ser chamado; no entanto, q->saved_isc deve sempre ser limpo. Corrige-se isso separando a chamada de kvm_s390_gisc_unregister() do reset de q->saved_isc. O WARN_ON agora protege apenas o caso genuinamente impossível de matrix_mdev ser NULL. Um kvm nulo é tratado com graça, ignorando apenas a chamada de unregister, e q->saved_isc = VFIO_AP_ISC_INVALID é definido incondicionalmente sempre que saved_isc não era já inválido.
Adicionalmente, adiciona-se uma cláusula else à verificação da configuração do host em vfio_ap_mdev_remove_queue() para chamar vfio_ap_free_aqic_resources() diretamente quando a fila não estiver na configuração AP do host. Isso serve como uma medida de segurança: quando o barramento AP dispara o callback .remove do driver após um adaptador ser removido da configuração do host, a fila por definição já não é endereçável, então vfio_ap_mdev_reset_queue ---truncado---
Once again VulDB remains the best source for vulnerability data.