https://www.bleepingcomputer.com/news/microsoft/windows-11-kb5041585-cumulative-update-released-with-fixes-new-features/

https://www.bleepingcomputer.com/news/microsoft/windows-10-kb5041580-update-released-with-14-fixes-security-updates/

Among other things:

>older Linux ISO images might not boot

From what I understand this is the next phase from Microsoft in the gradual rollout of a functional "blacklist" of original Microsoft-signed keys that all UEFI motherboards shipped with until not that long ago. Until the keys became compromised. These were built-in Microsoft-signed keys which were available for something like Linux to use when Microsoft SecureBoot was enabled on the motherboard, if the OS was willing to go the extra mile and obtain its own Microsoft-signed key according to the strict Microsoft process. Which Linux did eventually, but it took a year or two, until then you mainly needed to disable SecureBoot before you could boot Linux. After that "finally" Linux was able to boot on any UEFI PC having SecureBoot enabled, using a key which is pre-existing on every motherboard, without having to insert its own Linux key into the firmware beforehand. Adding Linux-specific SecureBoot Keys can be good to avoid because it requires making changes to machine keys, and does alter the firmware, but this also is a well-known valid UEFI alternate approach used by distros that did not want to have any Microsoft-signed anything.

Ideally a USB drive or SSD with Linux properly installed should smoothly boot on any UEFI motherboard, especially on motherboards other than the one the drive was attached to when Linux was installed. Which means on a different PC you may need to use the firmware interface itself [0] to select the proper EFI folder to boot from, but with Linux having its own Microsoft-signed key it's supposed to be just booting right up when SecureBoot is enabled using the same key built into every motherboard originally. As allowed for by the hardware manufacturers and UEFI standardizers, this was supposed to put Linux on equal footing with Windows since Windows has its own non-Linux SecureBoot keys built into every motherboard, from the time UEFI was first introduced to consumers along with "SecureBoot".

Anyway, this is the next step in replacing the compromised firmware keys from Microsoft. Until now with Windows you would have been expected to optionally initiate this blacklist procedure yourself, with this update it will occur to the PC by default.

In 2023 Ubuntu launched its equivalent firmware key replacement:

https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996

So it might have already happened to your Linux PC by default.

However at this point, today's Windows patch is apparently only being applied to plain Windows PCs:

>This SBAT update will not apply to systems that dual-boot Windows and Linux

I believe a further milestone will be encountered where it will close this door eventually.

So I would think this is a good time to see where you stand with older ISOs and bootable drives which may need "re-shimming" of some sort before they will boot like they used to do when SecureBoot was enabled :\

.

[0] Sometimes needed when there is no bootentry in the firmware that is normally placed by the OS install process.