技术干货 | CVE-2026-98214 漏洞复现

太初众测
太初众测

太初众测

2026年10月22日 08:26
山东

去阅读

CVE-2026-98214 漏洞复现

本文基于上游修复 commit、引入提交分析与实机复现整理。复现环境为 aarch64 虚拟机（Fedora 44 / 内核 7.2.0），复现过程全程在 SELinux Enforcing下完成，实测一个 uid=1001 的受限域进程成功执行了策略明确禁止的代码，并在打完官方补丁的内核上完成反向对照验证。

01 漏洞介绍

CVE-2026-98214 是 Linux 内核 SELinux 安全模块中的一个策略绕过漏洞，由 Karl Mehltretter于 2026 年 8 月披露并提交修复。

漏洞位于selinux\_file\_mprotect()：当文件来自嵌套overlayfs（堆叠文件系统）时，mmap()路径会对每一层的挂载者做安全检查，而 mprotect()路径只看得到最底一层——中间层的“禁止执行”检查凭空消失。

针对车联网在采用 Linux/Android的智能座舱、T-BOX、车载网关、域控制器及容器化车载服务中，可能成为“低权限入口到击穿 SELinux 隔离”的关键策略绕过环节。

一句话概括：一个连sudo都打不开的非 root 进程，先把文件“无害”地映射进内存，再改一次权限标志位，就跑起了SELinux明确禁止执行的代码。

它最反常的一点：全程不使用任何内存破坏技术——没有UAF、没有溢出、没有竞态，只是换了一条系统调用路径，强制访问控制的“禁止执行”就成了一张白纸；而且绕过成功的那一刻，审计日志里什么都不会多出来。

02 影响范围

3 个条件 同时成立 即受影响：

1. 内核包含引入提交82544d36b172 且不含修复 78fc54b934bf（Linux 7.2 至修复合入前的版本）；

2. SELinux 处于Enforcing 模式，且策略对堆叠文件系统中间层存在执行限制（容器 SELinux 策略的典型形态）；

3. 攻击者能触达由更高权限实体挂载的嵌套 overlayfs（容器运行时挂载的容器 rootfs 就是最常见的现成场景）。

• 受影响：Linux 7.2 及修复合入前的7.2.y point release；

• 不受影响：6.19.y 及更早分支——注意原因不是“已修复”，而是那套逐层挂载者检查根本不存在（mmap 路径也不查，无对照可言）；已合入 78fc54b934bf 的内核不受影响。

自检方法（需内核源码树或符号）：

在车联网场景中：采用 SELinux 强化的车端 Linux/Android Automotive系统、车端容器化服务（OTA沙箱、应用容器）若运行受影响内核，攻击者在获得低权限本地执行立足点后，可借此打掉SELinux 的执行限制策略，为后续提权链打开通道。不适用条件同样明确：SELinux未开启或处于 Permissive、系统未使用嵌套 overlayfs、内核不含引入提交的环境均不受影响。

03 修复建议

唯一可靠手段：升级包含修复提交 78fc54b934bf 的内核（7.2.y 后期 point release及对应 stable 分支，stable 回移编号4d50ebe5a277）。

没有可靠的临时缓解手段能等效修复。补丁空窗期内可做的：

•限制非特权user namespace：sysctl kernel.unprivileged\_userns\_clone=0，压缩低权限用户自建 overlay挂载的面；

• 梳理容器/沙箱运行时挂载的嵌套 overlay 挂载点，限制低权限进程对这些路径的触达；

• 审计日志关联排查：同一overlay路径上mmap的 { execute } 拒绝记录出现后，对应文件映射却变为可执行——这个组合即为可疑信号。

04 漏洞原理分析

4.1 专业术语背景介绍

背景关键点：

对内核而言，mmap(PROT\_EXEC)和mmap(PROT\_NONE)+mprotect(PROT\_EXEC) 是两条完全不同的代码路径，安全检查分别挂在两个钩子上——安全模型要求两条路径结论一致，而本漏洞正是不一致的产物。

4.2 漏洞原理与根因分析

overlayfs的安全问题是：挂载 overlay 的进程（mounter）有权读下层文件，但通过 overlay 访问文件的可能是权限更低的用户——典型如容器运行时（高权限）挂载镜像，容器内进程（低权限）读写文件。所以 SELinux 对堆叠文件系统实行双重检查：用户凭据查顶层文件，挂载者凭据（f\_cred）逐层查 backing file。

而 mprotect路径的全部输入只有一个 vma，vma->vm\_file 只存一个文件指针——mmap期间它已被 overlayfs 换成堆叠深处的 backing file，“中间隔着几层、各层挂载者是谁”这个信息在内核里没有任何地方保存：

对照两条路径：mmap 时“外层mounter vs 中间层文件{execute}”这一站真实存在且会拒绝；mprotect 时这一站根本不存在。于是同一文件、同一PROT\_EXEC权限，两条路径给出相反结论——绕过成立，且全程无竞态、100% 确定性。

根因一句话： mprotect 的 LSM 钩子只能看到 vma->vm\_file 单层指针，嵌套 overlayfs 的中间层挂载者检查在这条路径上结构性缺失。

修复（commit 78fc54b934bf）的思路正对病根：既然 mprotect 时层级信息已丢失，就在 backing file 打开时把每一层存下来--新增backing\_file\_security\_layer 结构记录每层的path与mounter SID，mprotect时通过backing\_mounters\_has\_perm() 对所有保存的中间层挂载者重新逐个检查，两条路径重新对齐。

4.3 白话介绍

把一个多层转包的建筑工地想象成这套系统：业主（用户）要进场施工（执行文件），工地被总包、分包层层转包（嵌套 overlayfs），安监规定每一层转包商的资质章都要检查一遍（逐层 mounter 检查），其中分包商那一层盖的是“禁止施工”章。

开工申请（mmap）走正门，窗口按流程逐层验章——总包、分包、底层供应商，一个不落，查到分包的“禁止施工”章，当场打回。但工地还有个“施工变更”窗口（mprotect）：工人先把物料以“仅堆放、不施工”（PROT\_NONE）的名义运进场，窗口见没有施工请求，逐层验章直接免了；随后工人去变更窗口把“堆放”改成“施工”（PROT\_EXEC）——这个窗口的台账上只贴着最底层供应商一家（vm\_file）的资质复印件，分包商那张“禁止施工”章的复印件从来没人誊进这本台账。窗口照章办事：业主资质、底层供应商，盖章放行。于是被明文禁止的施工队，在工地上真刀真枪干起活来（shellcode 执行），而安监日志里连一条新记录都不会有。

结果就是： 一道写在强制访问控制策略里的“禁止执行”，被两次合法的系统调用无声拆掉——正门铜墙铁壁，侧门无人把守。

4.4 攻击场景与触发条件

触发前提（漏洞层面）： 受影响内核 + SELinux Enforcing + 策略禁止某中间层执行 + 存在高权限者挂载的嵌套 overlayfs 且低权限进程可触达。

隐蔽前提（利用层面）： mounter 必须比攻击者权限高，否则绕过检查的是攻击者自己的凭据，没有收益；这决定了真实利用场景都是“容器/沙箱/系统服务挂载，低权限者访问”的形态。

典型攻击场景：

• 容器主机与容器嵌套：RHEL/Fedora/OpenShift上容器运行时以高权限域挂载多层overlay并用context= 染色，容器内低权限进程对runtime挂载的文件mmap(PROT\_NONE)+mprotect(PROT\_EXEC)，打掉容器 SELinux 策略的执行限制；

• Android / Android Automotive：SELinux 最严格的部署，untrusted\_app 域对 /data 的 execute 被严格限制，APEX/DSU 等机制由特权系统进程挂载文件系统堆叠——若受影响内核上这类挂载可被应用进程触达，即可绕过“禁止执行 /data 代码”的底座策略；

• noexec 加固的 Linux 服务器：依赖 SELinux 策略（而非挂载选项）实施“某目录禁止执行”的主机，策略被绕过等于 noexec 失效。

绕过能力： 无内存破坏、无竞态、确定性触发，KASLR/CFI 等内存层防护与此无关；SELinux Enforcing 本身就是要被打掉的对象。最要命的是检测面：绕过成功时不产生任何新的 AVC 记录——本该有的那条拒绝，从未发生。

4.5 漏洞复现

4.5.1 复现环境

选择 aarch64 而非 x86 的用意：证明该漏洞是纯逻辑缺陷，与 CPU 架构无关。

4.5.2 复现原理

4.5.3 复现过程与结果

攻击前基线（受限用户视角）：

运行 PoC 的终端实录（漏洞内核）：

终端复现实录（7.2.0 漏洞内核）

同一策略、同一场景、同一程序，在打过官方补丁的内核上反向对照：

补丁内核对照实录（7.2.0-patched：mprotect 被拒绝，payload 无法执行）

漏洞原理与完整利用链一图流：

从原理到利用一图流（地形 → 两条路径对比 → 利用三步）

复现结论验证项：

✅ 受限用户（uid=1001 + 自定义域）在 SELinux Enforcing 下执行了策略禁止的代码，全程身份未变——能力维度提权；

✅ execve 与 mmap(PROT\_EXEC) 两条基线均被拒，证明策略配置正确、拦截真实有效；

✅ 绕过 100% 确定性触发，无竞态、无崩溃、dmesg 无异常；

✅ 补丁内核上 mprotect 同样被拒，mmap/mprotect 两条路径 AVC 拒绝完全对齐，验证闭环；

✅ aarch64 环境复现，证明漏洞为架构无关的纯逻辑缺陷。

05 车联网相关性分析

该漏洞并非直接影响制动、转向等功能安全的漏洞，但对采用 Linux/Android的车端与云端链路具有明确的安全相关性。典型攻击链：攻击者一旦通过应用漏洞、调试接口或低权限账户获得本地执行权限，便可借此打掉 SELinux 的“禁止执行”策略（执行任意二进制/加载恶意原生库），将其作为提权链的中间环节，进一步配合权限提升漏洞篡改配置、植入持久化或横向移动。

实际车载量产系统多启用 SELinux Enforcing（Android Automotive 强制开启），且车端容器化服务与系统组件（APEX/OTA 沙箱）天然使用 overlayfs 堆叠挂载——与本漏洞的触发地形吻合。限制条件也写清楚：SELinux 处于 Permissive、无嵌套 overlay、内核不含引入提交的车型不受影响。车企应在 SBOM 与内核补丁基线中核查本 CVE，重点排查运行 Linux 7.2 早期版本的座舱与网关平台。该漏洞可视为 ISO/SAE 21434 网络安全风险中的本地策略绕过环节，而非直接的功能安全故障。

06 参考链接

• NVD 收录页：

https://nvd.nist.gov/vuln/detail/CVE-2026-98214

• 修复 commit（主线）：

78fc54b934bfb2c18aad8154c7302067146946f9 — “selinux: recheck intermediate backing files on mprotect()”

• 修复 commit（stable 回移）：

4d50ebe5a27724e020747ffd61a051dec67cb8ec

• 引入 commit：

82544d36b172（mmap 路径逐层挂载者检查，随 Linux 7.2 合入）

• 内核源码：

https://www.kernel.org/ （linux-7.2.tar.xz，SHA256 校验通过）

精彩回顾

END

扫码申请获取PoC