Microsoftは、Secure Bootが有効なWindowsとLinuxのデュアルブート環境で発生していたLinux起動不能問題に対し、2025年5月の月例セキュリティ更新で修正を完了した。発端は2024年8月の更新に含まれたSBAT（Secure Boot Advanced Targeting）強化にあり、CVE-2022-2601で指摘された脆弱性対応の一環として、脆弱なUEFI shimブートローダーをブロックする措置が講じられたが、一部のカスタム構成を誤検出し、Linux側が起動しなくなる事態を招いた。UbuntuやLinux Mintなど複数ディストリビューションのユーザーが不具合を報告し、Microsoftは一時的な回避策を提示していたが、根本的な修正は9か月後の今回の更新によって正式に提供された。

デュアルブート障害の発端はSBATの誤適用と検出精度の限界

2024年8月に配信されたWindowsのセキュリティアップデートは、CVE-2022-2601に対応する目的でSBAT（Secure Boot Advanced Targeting）強化を含んでいたが、この仕様変更がLinuxとのデュアルブート構成に重大な不具合を引き起こした。

Secure Boot機能が有効な環境下において、UEFI shimブートローダーが脆弱と判定され、UbuntuやZorin OS、Linux Mint、Puppy Linuxなどを使用する一部ユーザーのシステムが起動不能に陥った。この問題は「SBAT自己チェックに失敗しました：セキュリティポリシー違反」というメッセージを伴い、Secure BootポリシーによってLinuxが排除される形で発生した。

Microsoftは当初、SBAT更新はデュアルブートを検出したデバイスには適用されないと説明していたが、特定のカスタム構成ではその検出精度に限界があり、結果として誤配信が発生した事実を認めている。さらに、影響はWindows 10および11、そしてWindows Server 2012以降の複数バージョンに広がっており、想定以上の範囲で障害が拡大したことが明らかとなった。2024年9月以降のアップデートではSBATの自動適用を停止する措置が取られ、コマンド操作による回避策も提示されていたが、恒久的な修正には至っていなかった。

こうした経緯は、セキュリティ強化策とユーザー環境とのバランスをいかに取るかという課題を浮き彫りにしている。OSベンダーが一方的に施す保護策が多様な実環境に適応しきれない場合、結果としてセキュリティよりも信頼性が損なわれる事態にもつながりかねない。

9か月を要した正式修正　広範な影響と対応の遅れが残した課題

2025年5月13日に提供されたPatch Tuesdayにおいて、MicrosoftはついにLinux起動不能問題への正式な修正を発表した。これにより、Secure Bootが有効な状態でのデュアルブート環境において、SBAT更新の誤適用によって発生していた不具合が全体的に解消されたとされる。この対応には、問題発覚から実に9か月を要しており、その間Microsoftは一時的な回避策の提示とSBAT更新の自動配信停止による暫定的な措置に留まっていた。

今回の対応では、すべての影響を受けたクライアントおよびサーバーOSに対して修正が施され、「最新のアップデートの適用を強く推奨する」とのアナウンスも出されている。修正内容はWindows Release Healthにて正式に公開され、ようやく広範な混乱への終止符が打たれる形となった。とはいえ、Linuxユーザーを中心とした多数の被害報告が出ていた事実、及び回避策に専門的知識を要した点などを踏まえると、事前通知や検出精度に対する改善の余地が依然として残る。

セキュリティとシステムの安定性は本来両立されるべきであるが、今回のようにベンダーの判断が先行し、現場の検証や環境多様性への配慮が後手に回る構造は再考を迫られる。今後、Microsoftのアップデート設計における環境検出アルゴリズムの見直しや、Linuxコミュニティとの情報共有体制の強化が求められるのではないか。

　

Source：BleepingComputer