Linux内核CVE：向后移植（Backports）如何改变漏洞暴露情况

转载于 2026-08-21 10:33:49 发布 · 1 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

原文链接：https://www.onekey.com/resource/why-version-matching-is-not-enough-part-i-linux-kernel

GEO检测

介绍

为构建、集成或部署的固件生成软件物料清单（SBOM）的目的，不仅在于了解其中包含哪些软件组件及其版本，还在于将这些组件版本与已知的漏洞进行关联。

传统上，组件及其版本与一组已公开的漏洞之间的映射关系是通过通用平台枚举（CPE）来实现的。CPE是一个字符串，它以以下格式明确定义了受影响的组件：cpe:<cpe_version> :<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>，CPE本身与CVE相关联。

对于可能已有记录但未收录在官方CVE数据库中的漏洞，可使用PURL，其标准化格式如下：scheme:type/namespace/name@version?qualifiers#subpath。

该机制虽然运行良好，但存在两个主要限制条件：

1. 正确性。CVE编号管理机构（CNA）会为其发布的CVE分配正确的CPE，并维护这些CVE的CPE集合。

2. 表达能力。CPE 并没有提供足够的信息来说明CVE可达且可被利用的具体条件。这包括受影响的模块、函数、功能等。

我们将探讨这两个限制，并说明ONEKEY是如何应对这些问题的，以确保我们的客户不会被大量的误报淹没。我们将通过两个操作系统来说明我们的观点：Linux 内核和Android操作系统。

今天，我们先从Linux 内核开始讲起。

Linux内核背景

通用平台枚举（CPE）用于标识安全公告所描述的产品及版本。这可以很好地帮助CPE将组件清单与漏洞目录关联起来。

问题在于，当维护者进行补丁向后移植至稳定分支时，Linux CNA似乎并不总是能及时更新CPE信息。值得庆幸的是，ubuntu-cve-tracker、kernel-sec和cip-kernel-sec等项目维护着记录回溯移植情况的数据集，更精确地记录了补丁引入和修复的版本范围，这使我们能够优化从NVD CPE中提取的受影响版本信息。

在本项分析中，我们使用了三个需谨慎对待的术语：

● 原始NVD候选项：合并前的NVD CPE匹配器包含经过测试的内核版本。

● 支持向后移植的候选项：在通过ONEKEY的生产合并策略应用kernel-vulns和CIP分支范围后，原始比较集合中的该成员仍然保留。

● 评估改进：额外的确定性证据会改变所需工作量或质量。我们仅将独立证实未受影响的情况归类为误报。

我们使用的固定快照的原始NVD数据源包含14,269个带有 linux:linux_kernel CPE 匹配器的内核CVE。合并后的数据库包含14,503个内核CVE，其中包括仅在安全公告中提及的CVE——这些CVE会单独报告，而非被暗中计入缩减分母中。

稳定分支不会完全同步

主线修复程序通常会被向后移植到仍在维护的稳定分支中。该修复程序可能会在不同的日期和子版本中分别合并到 4.14.x、5.4.y 和 5.15.z 版本中。因此，即使某个特定的稳定内核版本已经接收了该修复程序，仅基于上游版本确定的适用范围仍可能在很长一段时间内仍可能有意保持较宽的范围。

我们的流程保留了衡量此项所需的两个阶段。它首先从固定的源代码树中解析原始的NVD匹配项，然后应用一种合并策略：若有kernel-vulns数据则以该数据为准；CIP数据提供嵌入式LTS的历史记录，并由不冲突的NVD范围填补空白。

未标题-1.png

在 Linux 4.4 的最终补丁发布中，原始比较包含4,226个候选项，经过稳定分支上下文处理后剩余2,692个，候选项减少了36.3%。在当前的Linux 6.18 补丁发布中，相应的数量分别为77和58，减少了24.7%。

这些数据并不是衡量NVD质量的评分标准。NVD数据集是发现研究的基准；第二个数据集则利用更新且针对特定分支的证据，回答了一个更具情境性的问题。

在子版本中，向后移植的情况才显露出来

单一地“最新 LTS”版本的比较可能会掩盖其中的机制。因此，对于4.14、5.4和5.15版本，我们分别选取了首个补丁版本、按时间顺序排列的补丁系列的中间版本，以及最终或当前的补丁版本。在进行统计之前，就已确定了这一选取规则。

Linux 4.14-1.png

Linux 4.14：首个补丁版、中期补丁版和最终/当前补丁版

Linux 5.4-1.png

Linux 5.4：首个补丁版、中期补丁版和最终/当前补丁版

Linux 5.15-1.png

Linux 5.15：首个补丁版、中期补丁版和最终/当前补丁版

例如，首个Linux 5.15补丁版本仅将原始候选项从6,800个减少到了6,521 个支持回溯的候选项，减少了4.1%。最终/当前样本中剩余候选项为1,118 个，但早期较差的结果仍显示在图表中。

规则覆盖不等于漏洞数量减少

版本细化仍无法告诉我们某个固件镜像实际编译进了那些内容。ONEKEY 会运行“自动化影响评估”，以确保我们不会报告实际上并不存在的问题：

自动影响评估功能会分析提取的固件文件，以识别并隐藏无法被利用的漏洞。本质上，该功能充当了一个过滤器，可帮助您专注于相关漏洞，从而简化漏洞分级流程。

在以下情况下，该漏洞被视为“无法被利用”：

1. 受影响的版本与您的固件中的版本不同。

2. 该漏洞影响的是未被编译进固件的功能或模块。

3. 该漏洞影响的是固件未实际使用的功能。

例如，如果某个漏洞只能通过蓝牙被利用，但您的固件运行在未安装蓝牙子模块的Linux内核上，那么该平台会自动过滤掉该漏洞。

对于影响Linux内核的CVE，我们可以自动推导出两种规则：

● 内核源代码规则：将函数和源文件信息关联到CVE

● 架构规则：将架构信息关联到CVE

在扫描Linux固件时，我们会从内核本身及其所有内核模块中提取内核符号。这些符号会通过按版本划分的查找表映射到相应的文件和函数上。在此基础上，我们可以结合内核源代码规则，利用这些信息来检查相关代码是否存在。

对于架构规则，我们只需检查您的内核是否是为受特定 CVE 影响的架构构建的。

下图显示了各 Linux LTS 版本中内核源代码规则和架构规则所占的比例。“任何自动化规则”这一项旨在展示自动化规则与手动编写规则之间的比例。

我们在这里刻意不减去那些受规则覆盖的 CVE。一个源规则可以根据二进制文件生成正向证据、负向证据，或者无法形成有效证据。同样，架构上下文也需要检测到的架构。规则覆盖表示具备进一步自动评估的条件；缩减则需要具体的固件映像和明确的决策规则。

实际应用示例

为了使下一步工作更具针对性，我们分析了连续五个OpenWrt发布的最终或当前补丁版本的官方Raspberry Pi 4 bcm27xx/bcm2711 squashfs工厂镜像：21.02.7、22.03.7、23.05.6、24.10.7和25.12.5。

OpenWRT Raspberry Pi 4 镜像-1.png

OpenWRT Raspberry Pi 4 镜像：发现、优化及影响证据

对于OpenWrt 21.02.7，内核检测功能识别出了跟踪记录中记录的版本，并生成了4,479个原始NVD候选项。通过考虑向后移植情况的版本范围筛选，从该比对样本中剔除了802个项。在同一组 NVD 比对样本中，自动化影响评估随后得出了2,830个负分匹配、80个零分匹配和767个正分匹配的最终结果。

对于OpenWrt 25.12.5，相同的固定流程从292个原始候选项开始，通过考虑向后移植的范围剔除 80 个，最终在该比较样本集中，根据所有评分符号得出 212 个最终匹配项。

该评分是证据权衡的结果，并非 CVSS 的替代方案，也不是可利用性判定的标准。负分意味着根据配置的规则，收集到的自动化证据倾向于表明该漏洞不会对当前固件产生影响。零分意味着分析发现了候选漏洞，但未改变证据权衡的结果。正分则表示发现了支持性证据。

因此，针对该特定的OpenWRT构建目标，我们的方法在5个版本中平均将CVE数量减少了78.6%（在21.02.7版本中减少了81%，在25.12.5版本中减少了79%）。