Microsoft is known for their signature, “my way or the highway” approach when it comes to their offerings, with the Windows operating system being the most prominent one among those.
Many in the FOSS community disagree with that approach, with a strong rejection of such practices, suggesting people go for more open options for their operating systems and applications, and I agree with them.
Unfortunately, that same approach has now affected many Linux distribution users, who were sent scampering searching for a fix to a problem caused by a Windows update (who would've expected that?).
Microsoft Slips Up: Linux Users Beware!
First spotted by Ars Technica, a monthly Windows update pushed on August 13 that included a fix to a two-year-old vulnerability, CVE-2022-2601, with an 8.6 CVSS severity rating, caused dual-boot systems with Windows and Linux distros to not boot.
That fix was meant to tackle an issue with the GRUB bootloader, which allowed malicious actors from carrying out-of-bound writes, and possibly bypass secure boot.
But, it caused some collateral damage in the process. After updating, many users, including users of Ventoy, and Ubuntu 24.04, reported that they were shown the following error:
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
This update installed an SBAT, which is an acronym for Secure Boot Advanced Targeting, a Linux-focused method for discarding various components in the boot path using generation numbers embedded into the EFI binaries. (apologies for the jargon)
However, this mechanism was meant to run with devices only running Windows, and, according to Microsoft, this should not have caused any issues on dual-boot systems, at least on newer Linus distributions.
But, as we know already, it did. 😑
Following these revelations, in a statement, Microsoft mentioned that they were aware of “some secondary boot scenarios are causing issues for some customers”, and that they were working with their Linux partners to investigate and address the issue.
Thankfully, the community has come to the rescue, with manutheeng, a member of the Linux Mint forums, finding a solution for Ubuntu in an old post on the Ubuntu forums.
The Solution
- First, disable Secure Boot from the UEFI menu.
- Then, log into Ubuntu with the user of your choice.
- Now, open a terminal and execute the following command:
sudo mokutil --set-sbat-policy delete
- After that, reboot your PC to see the changes.
- Now, if you'd like, you can re-enable Secure Boot from the UEFI menu.
The above steps should also work with any Ubuntu-based Linux distribution. If that doesn't work, then you might be facing what a Framework laptop user faced.
Closing Thoughts
If dual-boot systems were more common, then this issue would've been treated with more haste, like the CrowdStrike incident that took place last month, but that was not Microsoft's fault.
So, it's better than nothing. 🙂
Ultimately, there's still the matter of Secure Boot being an absolute mess, that has left many people questioning whether this could've been implemented in a better way.
I think that it could've, the PC industry rushed its implementation before it was ready.
💬 What about you? Were you impacted by these Windows update shenanigans? Let me know below!
Here's why you should opt for It's FOSS Plus Membership
- Even the biggest players in the Linux world don't care about desktop Linux users. We do.
- We don't put content behind paywall. Your support keeps it open for everyone. Think of it like 'pay it forward'.
- Don't like ads? With the Plus membership, you get an ad-free reading experience.
- When millions of AI-generated content is being published daily, you read and learn from real human Linux users.
- It costs just $2 a month, less than the cost of your favorite burger.
