Ubuntu内核修复为何按flavor分批?

前几天看到 CVE-2026-98432 的 CVSS 评分 9.8，我赶紧通过 SSH 登录 VPS，用 uname -r 查看内核版本。跑去 Ubuntu 的 CVE 追踪页一看，generic 那一行已经标记为修复，可我这台云镜像开的机器还停在老版本上。那一刻我的第一反应是：是不是我配错了源，还是漏掉了什么更新？

后来才慢慢理解，这不是漏了，是分批推进。Ubuntu 的 linux 包在追踪页上是按 release 和 flavor 分行列出的。generic、aws、gcp、oracle 这些 flavor 各有自己的构建和验证节奏，我盯着的那一行只代表它自己。云厂商镜像默认装的往往就是带 flavor 的包，所以“generic 修好了”和“我的机器修好了”完全是两件事。

为什么不能一把梭？我的理解是，不同 flavor 带着不同的驱动、配置和平台适配，得各自编译、各自测、各自走通道。把一堆 flavor 绑在一起发，风险会集中在一个时间点上，出问题也不好回退。分批发反而让每个 flavor 对自己的结果负责。

这件事给我最实在的教训是：别只看 uname -r。运行内核、已安装的内核包、软件源里的候选版本，是三件不同的事。我现在会顺手用 dpkg -l 'linux-image-*' 确认自己到底装的是哪个 flavor，再用 apt-cache policy 看候选版本来自 -updates、-security 还是 -proposed。看到 proposed 就别往生产上推，那只是预发布通道。

所以现在我不再纠结“为啥还没轮到我”，而是盯住自己那一行：复查追踪页、确认候选通道、该等就等，该用临时手段降低暴露面就先用上。分批不是拖沓，是让我这种小机器也能被单独照顾到。