CVE-2026-89960 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
s390/vfio-ap: corrige ponteiro pqap_hook obsoleto em caso de erro em vfio_ap_mdev_set_kvm()
Em vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook é definido como &matrix_mdev->pqap_hook antes que os bloqueios de atualização sejam adquiridos e a lista mdev seja verificada quanto a atribuições conflitantes. Se outro mdev já estiver conectado à mesma instância do KVM, a função retorna -EPERM sem restaurar o ponteiro hook, deixando kvm->arch.crypto.pqap_hook apontando para matrix_mdev com falha em vez do mdev que possui legitimamente o KVM.
Como matrix_mdev->kvm nunca é definido neste caminho de erro, vfio_ap_mdev_unset_kvm() não limpará o hook quando matrix_mdev for fechado posteriormente. Se matrix_mdev for liberado subsequentemente, qualquer instrução PQAP executada pela máquina virtual convidada desreferenciará o ponteiro obsoleto através de pqap_hook_rwsem, resultando em um use-after-free (uso após liberação).
Como kvm->arch.crypto.pqap_hook é definido apenas na função vfio_ap_mdev_set_kvm() e limpo na função vfio_ap_mdev_unset_kvm(), uma verificação para 'kvm->arch.crypto.pqap_hook != NULL' é tudo o que é necessário para determinar se ele pertence a outro mdev. Isso aliviará a necessidade de iterar pela lista matrix_dev->mdev_list para verificar se o objeto kvm está atribuído a outro mdev. Isso foi introduzido na v3 para aliviar a necessidade de adquirir os bloqueios dos mdevs ao iterar pela lista; no entanto, isso não impediu uma possível race condition (condição de corrida).
O pqap_hook_rwsem(write) é agora realizado dentro de get_update_locks_for_kvm(), que foi atualizado para adquirir pqap_hook_rwsem(write) entre kvm->lock e mdevs_lock. Essa ordem está consistente com o caminho de interceptação PQAP, que adquire pqap_hook_rwsem no modo read (leitura) enquanto srcu é mantido sob vcpu->mutex, estabelecendo a dependência: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read).
O pqap_hook_rwsem agora é liberado dentro de release_update_locks_for_kvm(), que foi atualizado para liberar pqap_hook_rwsem(write) entre mdevs_lock e kvm->lock.
Além disso, kvm_put_kvm() em vfio_ap_mdev_unset_kvm() foi movido após release_update_locks_for_kvm(). Anteriormente, era chamado enquanto kvm->lock estava mantido; se fosse a última referência, kvm_destroy_vm() seria executado sob kvm->lock, o que causaria um deadlock (bloqueio mútuo).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.