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.