CVE-2026-89929 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
KVM: nVM: Обеспечить эмуляцию INVVPID на правильном физическом процессоре (pCPU)
При эмуляции инструкции INVVPID KVM выполняет её на физическом процессоре, используя vpid02 (а не VPID, назначенный уровню L1), после выполнения некоторых проверок операндов. Однако возможно, что физический процессор, на котором KVM исполняет инструкцию INVVPID, отличается от того физического процессора, на котором работает уровень L2.
Например, в следующем сценарии: - Уровень L2 выполняется на CPU #1 и завершает работу (vmx->nested.vmcs02.cpu=1) - Уровень L1 мигрирует на CPU #2 и выполняет инструкцию INVVPID - KVM исполняет инструкцию INVVPID на CPU #2 - Уровень L1 возвращается обратно на CPU #1 и запускает уровень L2 (vmx->nested.vmcs02.cpu=1)
Записи в кэше TLB на CPU #1 никогда не инвалидируются, поскольку инструкция INVVPID была выполнена на CPU #2, а vmcs02 никогда не выполнялся на другом физическом процессоре (т.е. функция vmx_vcpu_load_vmcs() *не* запросит KVM_REQ_TLB_FLUSH).
Необходимо обеспечить выполнение инструкции INVVPID на том же самом pCPU, где последний раз работал уровень L2. Если это невозможно, следует использовать резервный механизм очистки last_vpid=0 для инициирования полной инвалидации VPID при следующем входе во вложенную виртуальную машину (так как KVM обнаружит использование уровня L1 другого VPID для уровня L2). Если уровень L2 окажется на другом pCPU, KVM все равно выполнит очистку TLB через vmx_vcpu_load_vmcs().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.