失效的假设
CVE-2024-26855 涉及 Intel ice 网卡驱动中的 ice_bridge_setlink()。该函数在 netlink 消息中查找网桥属性 IFLA_AF_SPEC。负责查找的 nlmsg_find_attr() 在该属性不存在时可能返回 NULL。存在漏洞的代码路径没有先做检查,就把结果传入了嵌套属性遍历。
审计时真正要问的,是两个操作之间的约定:这次查找承诺返回一个对象,还是返回一个可选结果?消息能够到达处理函数,并不意味着后续代码期望的每个属性都存在。
使用之前先校验结果
被接受的修复在查找之后立即检查 br_spec,缺失时返回 -EINVAL,从而在嵌套遍历之前拦下无效值。下面的片段展示了这一检查;它并不是一个可独立运行的复现程序。
把检查放在状态转换处,可以让下一位阅读代码的人看清这个假设。现在,代码会先确立后续操作所需的前提条件。
if (!br_spec)
return -EINVAL;在您自己的解析器中应检查什么
把每一次可选查找都跟踪到它第一次被使用的地方。将缺失字段、空集合和畸形输入与正常路径分开检查。确认辅助函数是通过 NULL、错误值还是单独的状态来报告失败,然后确认每个调用方都遵守了这一约定。
有价值的回归测试应当覆盖属性缺失的路径,并断言返回预期的错误。只包含完整消息的测试可能顺利通过,却让最初的错误假设原封不动。
对产品团队的实际启示
这是一个范围很窄、有具体修复的代码级缺陷。同样的审计思路也适用于应用解析器、协议处理程序和配置加载器:可选数据在经过校验之前,都必须被当作可选数据处理。
对于已安装的 Linux 系统,请查阅最新的 CVE 记录以及您所用发行版的软件包安全公告。由于存在回移植的修复,软件包状态比简单对比上游版本号更有参考价值。对于您自己的代码,一次聚焦的审计可以在处理不可信输入的各个组件之间追踪这些约定。
参考来源
漏洞记录
CVE-2024-26855需要在您自己的产品中检查这个问题吗?
安全代码审计想学会自己发现这类漏洞吗?
安全代码审计课程(一对一)