CVE-2025-40300
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 25 - wyżej niż 25% wszystkich znanych CVE
Streszczenie
W jądrze Linux dodano warunkową ochronę IBPB dla podatności VMSCAPE, która wykorzystuje słabą izolację predyktorów gałęzi między gościem a przestrzenią użytkownika (np. QEMU). Nowa łatka emituje IBPB po wyjściu z maszyny wirtualnej (VMexit) przed powrotem do przestrzeni użytkownika, co zwiększa bezpieczeństwo, ale może powodować spadek wydajności przy częstych przełączaniach.
Ocena ryzyka
Organizacja narażona jest na ataki typu side-channel, w których złośliwy gość może wpłynąć na predyktor gałęzi procesora, a następnie odczytać dane z przestrzeni użytkownika hiperwizora (np. QEMU). Brak tej łatki umożliwia wyciek poufnych informacji między maszynami wirtualnymi a procesami użytkownika.
Rekomendacja
Zaleca się natychmiastową aktualizację jądra Linux do wersji zawierającej tę łatkę (np. 6.13+ z odpowiednim backportem). W środowiskach z częstymi przejściami między hiperwizorem a użytkownikiem należy monitorować wydajność i rozważyć optymalizacje po zakończeniu embarga.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: x86/vmscape: Add conditional IBPB mitigation VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit. Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB. This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace. The intent is to integrate and optimize these cases post-embargo. [ dhansen: elaborate on suboptimal IBPB solution ]