微软的一次更新，却让Linux躺枪了。
大量Linux用户称，安装了微软的更新后，自己的Linux系统无法启动了。
受到微软更新影响的Linux用户，都是安装了Windows+Linux双系统。
突如其来的无法启动，让不少用户焦急万分，急忙发帖寻找解决方案。
结果，类似的反馈在Reddit和多个Linux社区铺天盖地出现。
出了这样的事后，有网友感慨，微软不可能针对Linux做事无巨细的测试，双系统还是通过虚拟机实现更加保险。
还有网友认为这并非是个意外。
毕竟在之前微软就试过通过安全启动阻止Windows 10用户启动其他操作系统。
作为替代方案，微软还推出了WSL，从而能够在Windows当中运行Linux子系统，以满足用户的双系统需求。
微软修漏洞，Linux躺枪
此次事件中受到波及的，是Windows+Linux的双系统用户。
安装更新后，这些用户在启动Linux时会发生报错，提示“出现严重错误”。
Verifying shim SBAT data failed: Security Policy Violation.
shim SBAT数据校验失败：违反安全策略
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation.
出现严重错误：SBAT自检失败：违反安全策略
△图源：Reddit/paku1234
Debian、Ubuntu等多个发行版本，无论新旧都遭了殃，甚至U盘和光盘启动也出现了类似情况。
而这背后的直接原因，就是微软新发布的一款补丁。
补丁修复的是两年前曝出的一个漏洞，代号为CVE-2022-2601，CVSS严重程度评分为8.6（最高10）。
该漏洞与GRUB有关，GRUB是启动许多Linux设备都在用的开源引导加载程序。
利用该漏洞，黑客能够绕过安全启动机制，该机制是一套确保操作系统启动过程中不会加载恶意固件或软件的行业标准。
微软在有关CVE-2022-2601的公告中解释，针对该漏洞的更新将安装SBAT（一种用于屏蔽启动路径中各种组件的Linux机制）。
这样一来，Windows设备上的安全启动被利用该漏洞的GRUB包攻击的概率就会降低。
同时微软还信誓旦旦地表示，装有Linux的设备不会受到这次更新的影响。
△早期GRUB界面
但事与愿违，不仅Linux出现了故障，还有其他程序也受到了SBAT的“戕害”。
有网友表示，自己的软件带有网络引导功能，由于也利用了GRUB，在按照更新后也会无法运行。
要想解决，就要把系统中所有设备的安全启动全都禁用，或者删掉SBAT文件。
有用户对微软的这波操作不解，质疑为什么微软要去修复一个本不属于Windows、自己也“一无所知”的模块。
微软回复被现实“打脸”
对于这一波故障，微软这边给出的回应是这样的：
当检测到Linux启动选项时，此更新不会被应用。
我们知道，某些辅助启动方案会给某些客户带来问题，包括使用“过时的”Linux加载程序。
我们正在与Linux合作伙伴合作，调查问题原因和解决方案
实际上，基本和CVE-2022-2601发布时的公告内容没什么区别：
SBAT值不适用于同时装有Windows和Linux的双启动系统，理论上也不会影响这些系统。
版本较旧的Linux发行版可能无法启动，如果发生这种情况，请与您的Linux供应商合作获取更新。
但微软的说法多少有些自打自脸了——如果不是双系统，单用Linux自然也不会出现这种故障。
还有人发出灵魂提问——要是只用Windows，谁会装GRUB啊？
抓马的是，实际情况也并非像微软说的那样影响的都是旧版Linux，出现故障的系统有一些正是新版（如Ubuntu 24.04、Debian 12.6.0）。
不过也有网友神评论说，微软其实也没说谎，因为装完补丁之后Linux启动不了，就不算是双系统了
。
另外，有热心网友提出了应急补救措施——
首先进入BIOS关闭安全启动，目的是先进入到Linux系统。
之后利用命令行把引发故障的SBAT策略删除，然后重启让设置生效。
最后，再次进入BIOS重新打开安全启动，问题就暂时解决了。
