CVSS分歧下如何做本地风险判断?

同一个漏洞，内核团队和 Ubuntu 给出 9.8，SUSE 和 Amazon 给 8.1，Red Hat 只给 5.9。三份公告摆在一起，评分差了一截，很多人第一反应是“到底谁说得对”。其实这问题问偏了：CVSS 描述的是漏洞在最坏假设下能造成多大破坏，不是咱们手上这台机器到底有多危险。拿它当风险结论，就像看天气预报说“全国可能下暴雨”，然后决定自己家要不要收衣服。

以这次 linux 内核 IPv4 TCP 握手的释放后使用问题为例，公开信息说影响 4.4 及之后的内核版本，远程、不需要账号就能触达。评分分歧的根源，是各家对攻击路径和前置条件的假设不同。公告写的是“可能性”，而本地要回答的是“我这台机器，在这个版本、这套配置、这个网络位置下，到底能不能被碰到”。

判断这事，先看三个条件是否同时成立：运行内核落在受影响区间、修复包没装或没生效、IPv4 TCP 端口对外可达。三个缺一个，风险量级就完全不同。一个只监听回环地址的服务，和一个绑在 0.0.0.0 又被安全组放行的服务，根本不是一个故事。

有个坑挺常见：补丁包装上了，但机器几个月没重启，跑的还是旧内核。清单上显示“已修复”，实际漏洞还在。所以版本要分两栏记，安装状态和生效状态分开写，别混成一句“已更新”。

还有个误判值得提一句。公开分析里的利用样本走了 MPTCP 路径，但这不代表没开 MPTCP 就安全。把样本的特征当成漏洞的前提，是把“别人怎么打的”错认成“只有这样才能打”。

如果授权只允许只读检查，那就老老实实写“版本命中、暴露面存在、可利用性未独立验证”，把没验证的部分列成后续动作。用推测填空，报告好看，但经不起复核。真要验证，也是在隔离环境里做修复前后的差分对比，而不是在生产机上试。

说到底，CVSS 的分歧不是让咱们选边站，而是提醒：评分是别人的假设，风险是自己的资产。把版本、配置、可达性逐台确认清楚，比记住那个分数有用得多。