Correction de bug : Microsoft rend de nouveau opérationnel le dual-boot Windows/Linux

Écrit par Guillaume
Publié le : {{ dayjs(1747843201*1000).local().format("L").toString()}}
Suivez-nous

Depuis neuf mois, le dual-boot Windows/Linux pouvait ne plus fonctionner du fait du blocage des bootloaders vulnérables à une faille critique.

Comme l’explique Microsoft lui-même dans le journal de suivi des correctifs, le déploiement du correctif de sécurité (KB5041160) avait entraîné un problème substantiel pour nombre d’utilisateurs amateurs de dual-boot Windows/Linux. En effet, dans pas mal de cas, le dual-boot n’était tout simplement plus fonctionnel avec un message d’erreur de ce type « Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation ». Un problème qui, de base, est déjà gênant, mais qui en plus a eu le mauvais goût de durer puisqu’il remonte tout de même au mois d’août 2024 !

Microsoft vient donc de confirmer au travers de la mise à jour KB5058385 du 13 mai dernier que le bug appartient maintenant au passé. Le correctif est donc intégré à cette mise à jour déployée depuis quelques jours et qui permet un redémarrage fonctionnel, sans qu’il soit nécessaire de réaliser quelque opération que ce soit. Il est à noter que le correctif résout le problème sur tous les systèmes qui étaient concernés, c’est-à-dire Windows 10, Windows 11 ainsi que Windows Server. Comme le précise Microsoft, il « corrige les effets indésirables de la mise à jour SBAT ».

Rappelons que la mise à jour KB5041160 d’août dernier n’était pas pensée pour mettre le bazar dans les configurations multi-boot. Elle avait pour objectif le blocage des bootloaders vulnérables à une faille critique de GRUB2 (CVE-2022-2601). Problème, sur certaines distributions Linux – ce qui expliquerait pourquoi tous les utilisateurs du dual-boot n’étaient pas touchés – la version corrigée de GRUB2 n’avait pas été intégrée ou, ce qui revient finalement pratiquement au même, n’avait pas été signée par Microsoft. De fait, le processus Secure Boot ne pouvait plus fonctionner correctement. Microsoft a tardé à réagir – c’est le moins que l’on puisse dire – mais il n’était clairement pas le seul fautif dans cette histoire.