Secure Boot
Secure Boot is a security standard that all PC manufacturers implement, that ensures a trusted OS is being run on the computer. Because the PC ecosystem is pretty open, the set of "trusted OS" includes many Linux distributions as well. It ensures that any OS being loaded is legitimate.
Secure Boot has, over time, turned into a patchworked mess, with multiple vulnerabilities being unearthed recently.
Things are complicated further with the standard being open to all Operating Systems, but with Microsoft being the player most obsessed with its security and functionality.
The GRUB Bootloader
GRUB is a bootloader which is used by a lot of Linux distributions. People that dual-boot their systems prefer to use the GRUB bootloader because it offers a choice between booting to Linux or Windows on every boot. The default Windows bootloader does not offer a choice, booting directly into Windows instead.
A Two-Year-Old Vulnerability In GRUB
GRUB's font rendering function had a buffer overflow vulnerability. The details are unclear to me, but a maliciously crafted font could, in theory, bypass the protections provided by Secure Boot.
What's A Buffer Overflow?
A buffer is a set of memory allocated to a program. Sometimes, a program may write data beyond its allotted memory, into memory spaces allotted to a different program. This is a buffer overflow and great care is taken to avoid these.
A carefully crafted input to the first program can then inject data into the memory of the latter program, enabling an attacker to manipulate it.
Microsoft's Fix
Microsoft's monthly update contained a mechanism (called SBAT) to revoke certain components on the boot path (please don't ask me what this phrase means), which would harden Secure Boot on computers that have installed compromised versions of GRUB packages. They would install this on devices that are configured to run only Windows, meaning that dual-boot devices would be excluded from the update.
In theory.
In practice, there seemed to be no exclusion. In Microsoft's words, "some secondary boot scenarios are causing issues for some customers, including when using outdated Linux loaders with vulnerable code", but that seems like corporate-speak for "we messed up".
I say this because companies tend to downplay the prevalence of any issues with their products with phrasing such as "a small percentage of devices", when they have simply cut corners while testing.
Support forums lit up with complaints, with everyone who downloaded the update suffering from being (sorta) unable to boot into Linux. It didn't matter which distro they were on. Ubuntu, Debian and Linux Mint, were all affected. Some people managed to skip the update entirely by not opening Windows during the time when this flawed update was live (no I'm not showing off).
There were multiple ways to fix this issue. One was to turn Secure Boot off in the BIOS settings and just using the computer like that. For users who cannot accept this lack of protection, they could temporarily turn Secure Boot off, log into Linux, delete the offending SBAT policy, and then re-enable secure boot on the next login.
This seems to be another sloppy update, right on the heels of CrowdStrike's own sloppy update. That one took out Windows, this one took out Linux.
To Microsoft's credit, it does seem like they phased the update, but I'm not entirely sure if they tested the "exclude all dual-boot systems" logic properly. Shows a blatant disregard for Linux users, in my completely biased opinion.
On a related note, Secure Boot has had other vulnerabilities. One of them was human error, plain and simple, with a private key being accidentally uploaded to a repository on github. Another vulnerability, somewhat similar to this one, is present in the UEFI's logo parser.