Per Microsoft, "You might find that older Linux distribution ISOs will not boot."

I guess their definition of "older Linux distribution ISOs" includes the current Ubuntu and Debian ISOs.

https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2022-2601

While Microsoft claims "The SBAT value is not applied to dual-boot systems that boot both Windows and Linux", is this always true?

If I have a Windows system that I sometimes boot into Linux from a USB drive, will Windows Update be able to detect this? Of course not. What if I use some sort of other unexpected "dual boot" mechanism? Will Windows Update detect this? Maybe.

With the August Microsoft SBAT update, SecureBoot will fail to boot any EFI module that specifies anything less than shim,4

What does the Ubuntu 24.04 ISO specify?
shim,2

This is why the Ubuntu 24.04 (and others) ISO won't boot on a SecureBoot system that has the August SBAT updates that Microsoft pushed out.

Aside from those unfortunate souls who have a dual-boot system that both wasn't detected by Microsoft and also is out of date enough so that its boot bits are noncompliant, who else might be affected by this?

Ventoy will fail to work on a SecureBoot-enabled Windows system with August's updates. The current Ventoy doesn't have a "shim,4" compliant EFI bootloader.

You can fix this if you don't care to wait for Ventoy to fix this.
Or do what probably a lot of people do, which is disable SecureBoot and forget to ever turn it back on again.
https://github.com/ventoy/Ventoy/issues/2692#issuecomment-2031412234

Note that Ubuntu is (now) aware of their need to roll new install ISOs:
https://bugs.launchpad.net/ubuntu/+source/cd-boot-images-amd64/+bug/2076929

Though I will say that I'm a touch surprised that Microsoft deploying a mitigation for a 2-year old vulnerability in a signed UEFI module is affecting current OS releases in 2024.

Back to Microsoft's "The SBAT value is not applied to dual-boot systems that boot both Windows and Linux"

What causes the SBAT value to be installed?
You boot into Windows TWICE after installing August's updates. That's it. Booting into Windows twice fails Microsoft's test of whether a system is a dual-boot system. 🤦‍♂️

If you've used Windows twice since installing August's updates, you lose the ability to SecureBoot into Linux if your distro has out-of-date signed Grub stuff. (e.g. Ubuntu 22.04)

Here is a system that dual boots Windows 11 and fully-patched Ubuntu 22.04. If you boot into Windows twice, you lose the ability to SecureBoot into Ubuntu 22.04.

Even if Microsoft were successful in their failed "The SBAT value is not applied to dual-boot systems that boot both Windows and Linux" strategy, let's think about the consequences of if it were successful.

The goal was to have some subset of Windows systems out there *not* get a Patch Tuesday CVE update. Presumably due to the fact that because Microsoft has the keys to the SecureBoot kingdom, actions that they take to protect Windows itself has a trickle-down effect that potentially affects every PC out there, including non-Windows operating systems.

Luckily (?), Microsoft seems to have failed in their attempt to limit who gets the CVE-2022-2601 mitigation.

In case it's not obvious by now, SecureBoot is messy. 😬

Did Ubuntu mess up by not deploying a fix for CVE-2022-2601 in 22.04?

Actually, no. Ubuntu DID deploy a fix for CVE-2022-2601. And bootloaders that contain the fix will have:
sbat,1,2022111500
shim,2
grub,3

See https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt for more detail.

Why did Microsoft's August SBAT update break Ubuntu and others?
While Microsoft said that they are mitigating CVE-2022-2601 in August, the SBAT they have deployed is actually to protect against:
* CVE-2023-40547
* CVE-2023-40546
* CVE-2023-40548
* CVE-2023-40549
* CVE-2023-40550
* CVE-2023-40551

Is deploying this SBAT a bad thing?
No. In the SecureBoot world that Microsoft has created, THEY are responsible for pushing out mitigations that might have collateral damage.

Is saying that the AUGUST SBAT update fixes CVE-2022-2601 a bad thing?
ABSOLUTELY.

If the update mitigates 6 vulnerabilities newer than CVE-2022-2601, then picking CVE-2022-2601 as the CVE to use for the update is clearly wrong. Maybe use one of (or all of) the 6 CVEs that the mitigation is for?

Who am I kidding. Microsoft abuses everything about CVE, so this all should be a surprise to nobody.

If anybody has been playing along with the "what SBAT does my system have?" game, take caution:

In a true heisenbug sense, note that the Linux ISO you boot with may *itself* update the SBAT of the system you are inspecting.

For example, the process of booting a Mint 22 ISO on a Windows system to check the SBAT level will in and of itself update the SBAT to the level that protects against CVE-2022-2601. As such, I previously (incorrectly) concluded that a July 2024 Windows 11 system already has a mitigation for CVE-2022-2601. This is not correct. I fell victim of using a tool for measuring something that actually changes the thing I'm measuring before I got the chance to make the measurement. 🤦‍♂️

Booting such a system with an Ubuntu 22.04 Server ISO will show that July 2024 Windows 11 does *not* have a CVE-2022-2601 mitigation.

The August SBAT update that Microsoft pushed out for CVE-2022-2601 does indeed block CVE-2022-2601 exploitation. And it appears to be the first time that Microsoft has deployed an SBAT update to Windows systems. However, it also has mitigations for half a dozen *newer* CVEs.

Microsoft does indeed have an update page for CVE-2023-40547 (RCE in HTTP boot support):
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-40547

But they didn't bother with CVE-2023-40546, CVE-2023-40548, CVE-2023-40549, CVE-2023-40550, or CVE-2023-40550.

The fact that Ubuntu (and friends) wasn't prepared for mitigations being deployed for a set of 7-month-old vulnerabilities is, well, disappointing. Folks living in the SecureBoot world are going to have to be prepared for such an update happening, and one very well may happen like this again in the future. Hopefully distros will take SecureBoot-related updates more seriously in the future.