内核补丁生效状态的管理盲区

内核补丁管理中最隐蔽的失误，往往不是漏装，而是把“已安装”错当成“已生效”。资产清单上标记为已修复的主机，实际运行的内核可能仍是旧版本——补丁包躺在磁盘上，直到下一次重启才会真正接管。这个时间差可以长达数月，而漏洞窗口也就在这段静默期里持续敞开。

盲区的成因并不复杂。多数发行版在安装内核更新后不会强制重启，业务连续性要求又让重启排期一再后延。于是出现一种典型状态：包管理器显示修复包已就位，uname -r 输出的仍是旧内核，两者分别对应“安装状态”和“生效状态”，却常被合并成同一个勾选项。CVE-2026-98432 这类落在 TCP 握手路径上的问题，恰好说明为何不能含糊：只要运行内核未切换，即便修复包版本与厂商公告一致，代码路径上的缺陷依然存在。

更细的盲区出现在 livepatch 和 kexec 场景。补丁机制处于激活状态，并不等于它覆盖了目标 CVE 涉及的具体函数。livepatch 是否包含该修复，必须回到厂商公告逐条核对，而不是看模块是否加载。第三方内核模块同样会改变实际行为，镜像一致的多台主机可能因模块差异而处于不同修复状态。把这些变量纳入清点，才能避免“同一镜像等于同一结论”的误判。

管理上可行的做法是把状态拆成三层分别记录：运行中内核版本、已安装内核包版本、可引导条目指向的版本。三者不一致时，清单应显式标注“待重启生效”，而不是简单归入已修复。重启本身对业务的影响常大于漏洞验证动作，因此需要单独走变更流程，并在变更前确认旧内核条目仍在引导菜单中、/boot 空间充足、控制台访问可用，回滚路径才算成立。

复测环节要回到最初那条假设逐项确认：运行内核是否已包含修复、修复包版本是否与公告一致、重启是否真正切换了内核、暴露面是否与清点时相同。缺少任何一项，“已修复”都只是纸面结论。对暂不能重启的资产，补偿控制可以收紧暴露面，但只能降低触发概率，不能替代补丁生效，这一点应在遗留风险记录中写明责任人与到期时间。

补丁管理的成熟度，不体现在安装了多少包，而体现在能否准确回答“此刻正在运行的内核，是否真的带着修复”。把安装与生效分开度量，盲区才会从默许状态变成可追踪的显性项。