Le 8 novembre 2026, Phoronix a rapporté qu’un défaut de sélection dans Linux pouvait laisser désactivée la protection contre Branch History Injection (BHI) dans certaines configurations, notamment avec un noyau compilé sans KVM. Une correction figurait alors dans une demande d’intégration x86 (pull request).
Comment le choix de la protection pouvait échouer
Selon Phoronix, bhi_select_mitigation() pouvait choisir BHI_MITIGATION_OFF lorsque CPU_MITIGATE_GUEST_HOST n’était pas activé, même si CPU_MITIGATE_USER_KERNEL l’était. La logique pouvait donc laisser de côté la protection contre les attaques visant le noyau depuis l’espace utilisateur, parce que le réglage concernant les attaques invité-vers-hôte était désactivé.
La désactivation de KVM pouvait couper l’indicateur guest-to-host sans supprimer le besoin de protection user-to-kernel.
Pourquoi un noyau sans KVM pouvait encore avoir besoin de BHI
Dans l’exemple rapporté, un noyau compilé sans KVM pouvait désactiver par défaut CPU_MITIGATE_GUEST_HOST. Cela ne signifiait pas que la protection contre les attaques user-to-kernel devenait inutile. Phoronix indique aussi que le paramètre de démarrage mitigations=auto,no_guest_host pouvait conduire au même choix de mitigation.
Ce que proposait la demande d’intégration x86
L’entrée du pull request x86 attribuée à Breno Leitao proposait de choisir la mitigation BHI en fonction du vecteur d’attaque (liste de diffusion du noyau Linux). Cette approche vise à tenir compte séparément des vecteurs user-to-kernel et guest-to-host.
Dans son compte rendu du 8 novembre, Phoronix indiquait que l’intégration était attendue avant Linux 7.4-rc2 et que des rétroportages étaient prévus pour les branches prises en charge depuis l’introduction de BHI en 2022.
Quels processeurs étaient concernés
Phoronix rapportait que, sur les processeurs Intel concernés, le défaut pouvait laisser de côté par défaut BHI_DIS_S ou la boucle d’effacement du BHB. L’article mentionnait également certaines configurations de processeurs ARM et AMD.
