Getty Images
Last Tuesday, several Linux users—many of them using packages released earlier this year—started reporting that their machines were failing to boot. Instead, they received a mysterious error message that included the phrase: “A serious error has occurred.”
Reason: A to update Microsoft released this update as part of its monthly patch release. It was intended to close Weakness at 2 years old in gruban open-source boot loader used to boot many Linux machines. The vulnerability, which received a severity rating of 8.6 out of 10, allowed hackers to bypass Secure Boot, the industry standard for ensuring that devices running Windows or other operating systems don’t load firmware or malware during the boot process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft only patched it last Tuesday.
Many operating systems, new and old, are affected.
Tuesday’s update left dual-boot devices — those configured to run both Windows and Linux — unable to boot into the latter when Secure Boot was enforced. When users tried to load Linux, they received the message: “SBAT shim data check failed: Security policy violation. Serious error occurred: SBAT self-check failed: Security policy violation.” Almost immediately Supports and discussion Forums lit up with Reports The follower to fail.
“Note that Windows says this update will not apply to systems running both Windows and Linux,” one frustrated person wrote. “This is clearly not true, and likely depends on the system configuration and distribution being run. This appears to have made some linux efi shim bootloaders incompatible with microcrap efi bootloaders (this is why switching from MS efi to “other OS” in efi setup works). Mint appears to have a shim version that MS SBAT does not recognize.”
Several distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, and Puppy Linux, are all reportedly affected. Microsoft has yet to publicly acknowledge the bug, explain how it was not discovered during testing, or offer technical guidance to those affected. Company representatives did not respond to an email requesting answers.
Microsoft’s bulletin for CVE-20220-2601 explains that the update will install coma— Linux’s mechanism for eliminating various components in the boot path—but only on machines configured to run Windows only. This way, secure boot on Windows machines would not be vulnerable to attacks carrying the GRUB package that exploits the vulnerability. Microsoft has assured users that their dual-boot systems will not be affected, though it has warned that machines running older versions of Linux may experience problems.
“The SBAT value does not apply to dual-boot systems that run both Windows and Linux and should not affect these systems,” the bulletin reads. “You may find that ISO files for older Linux distributions do not work. If this happens, work with your Linux vendor to obtain an update.”
In fact, the update He has It is applied to devices that run both Windows and Linux. This includes not only dual-boot devices but also Windows devices that can run Linux from ISO imageOr a USB drive or optical media. Additionally, many affected systems are running recently released versions of Linux, including Ubuntu 24.04 and Debian 12.6.0.
What now?
With Microsoft maintaining wireless silence, those affected by the flaw have had to find their own workarounds. One option is to access their EFI panel and turn off Secure Boot. Depending on the user’s security needs, this option may not be acceptable. The best short-term option is to remove the SBAT that Microsoft pushed out last Tuesday. This means that users will still receive some of the benefits of Secure Boot even if they remain vulnerable to attacks exploiting CVE-2022-2601. The steps for this workaround are outlined below. here (Thank you for Nothing (For reference).
The specific steps are:
1. Disable Secure Boot
2. Log in to your Ubuntu user and open a terminal.
3. Delete the SBAT policy with:code: Select all
sudo mokutil –set-sbat-policy delete
4. Restart your computer and log back into Ubuntu to update the SBAT policy.
5. Restart and then re-enable Secure Boot in BIOS.
This incident is the latest to underscore just how messed up Secure Boot has become—or perhaps always has been. Over the past 18 months, researchers have discovered at least four vulnerabilities that could be exploited to completely disable the security mechanism. The most recent incident involved test keys used to authenticate Secure Boot on nearly 500 device models. The keys were prominently marked “Don’t Trust.”
“Ultimately, while Secure Boot makes Windows more secure, it appears to have a growing set of flaws that make it not quite as secure as intended,” said Will Dorman, a senior vulnerability analyst at security firm Analygence. “SecureBoot is getting messy because it’s not a Microsoft-only game, even though they hold the keys to the kingdom. Any vulnerability in a SecureBoot component could only affect Windows that supports SecureBoot. So Microsoft has to address/block the vulnerable stuff.”
