授权渗透测试核验 Linux 内核 IPv4 TCP 漏洞（CVE-2026-98432）：从版本与配置排查到补丁确认与回滚

CVE-2026-98432 是 linux 内核 IPv4 TCP 连接建立路径中的一个释放后使用（use-after-free）问题，公开信息显示它影响 4.4 及之后的内核版本，远程、未认证的对端在特定条件下可以触达。不同厂商给出的 CVSS 评分差异明显：内核 CVE 团队与 Ubuntu 给出 9.8，SUSE 与 Amazon 给出 8.1，Red Hat 给出 5.9。这种分歧本身就说明一件事：漏洞公告描述的是“最坏情况下的可能性”，而授权测试要回答的是“我负责的这台资产，在当前版本、配置和网络位置下，是否真的具备被触发的条件”。本文按资产清点、假设形成、受控验证、证据记录、风险判断、补丁确认与回滚的顺序，给出一条可复核的排查链，重点放在如何区分“补丁未装”和“实际可被利用”，以及如何在不制造业务风险的前提下把结论写清楚。

测试边界与前置条件

这类漏洞的排查很容易滑向两个极端：要么只看扫描器一条命中就宣布“ critical ”，要么因为“没见到公开利用”就搁置。两者都不适合作为报告结论。开始之前，先把边界写进授权文档和工单：

• 书面授权中列明资产范围、可执行的操作类型、禁止事项（尤其是在生产环境发送构造报文、触发内核崩溃、重启业务节点）以及应急联系人。
• 明确测试窗口和变更审批。内核补丁通常需要重启，重启本身对业务的影响往往大于漏洞验证动作，必须单独走变更流程。
• 约定证据保全方式：命令输出、包版本、时间戳、执行人和复核人，避免事后只剩一句“已确认”。
• 明确“验证”与“利用”的分界。本文不提供针对生产环境的破坏性利用步骤；受控环境中的验证也应以观察行为差异和确认修复为目标，而不是取得 shell。

如果授权范围只允许只读检查，那就把结论限定在“版本命中 + 暴露面存在 + 可利用性未独立验证”，并把未验证部分写成后续动作，而不是用推测填补。

第一步：资产与暴露面清点

先回答三个问题：这台资产跑的是什么内核、由谁提供补丁、它的 IPv4 TCP 端口对谁可达。三者缺一，风险判断都会失真。

内核版本与包版本要一起看。uname -r 只说明当前运行的内核，不能说明已安装的最新包，也不能说明重启后会不会切换。建议在每台主机上采集：

uname -r
cat /proc/version
# Debian/Ubuntu
dpkg -l 'linux-image*' | grep ^ii
# RHEL 系
rpm -qa 'kernel*' | sort

输出要按“运行中内核 / 已安装内核 / 可引导条目”三列整理。常见误判是：补丁包已经安装，但主机长时间未重启，运行内核仍是旧版本；或者多台主机共用镜像，包版本一致，但其中几台通过 livepatch 或第三方内核模块改变了实际行为。若使用 livepatch，需要确认厂商是否已覆盖该 CVE，不能仅凭 livepatch 处于激活状态就判定已修复。

暴露面清点关注“谁能到达哪个 IPv4 TCP 监听端口”，而不是“开了多少端口”。至少记录监听地址、绑定接口、安全组或防火墙放行范围、是否存在公网映射、是否有反向代理或四层负载均衡在前置。一个只监听回环地址的服务，与一个对 0.0.0.0 监听并被安全组放行的服务，风险量级完全不同。

ss -lntp
nft list ruleset        # 或 iptables-save，视环境而定
ip -4 addr show
ip route

云环境还要单独核对安全组、网络 ACL 和负载均衡监听器，主机内的 ss 输出不足以证明外部可达性。

第二步：把公告翻译成可检验的假设

公开资料给出的受影响范围是 linux 4.4 及之后、直到各稳定分支修复版本之前。上游修复出现在 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 和 7.3 等版本，具体到发行版仍要以厂商公告为准。触发位置在 IPv4 TCP 握手相关代码路径，公开分析指向 tcp_v4_syn_recv_sock() 与 ip_options_build() 一带；攻击者不需要账号，也不需要用户交互，但需要能够向目标主机的 IPv4 TCP 端口发送报文。

这里有两个容易写错的判断。第一，不能因为目标未启用 MPTCP 就认定不受影响。Ubuntu 的公告提到，目前已知的、由 Anthropic 研究模型生成的利用样本使用了 MPTCP 路径，但同时明确说明该漏洞并不专属于 MPTCP；把“未启用 MPTCP”当作豁免条件，是把利用样本的特征误当成了漏洞的前提。第二，不能把厂商评分直接搬进报告当作本资产的风险值。9.8、8.1、5.9 的差异来自对攻击路径、前置条件和影响面的不同假设，报告里应说明采用的是哪个评分、为什么，以及本地暴露面是否改变了这个假设。

把上述信息写成一条可检验的假设，例如：

主机 A 运行 5.15.0-xx 内核，未安装对应发行版修复包；其对公网开放 443/TCP，经安全组放行；因此该主机处于受影响区间且具备远程可达的握手套接字路径，理论上满足触发前提。可利用性待受控环境验证。

假设写得越具体，后面的验证和复测就越容易对齐。

第三步：在受控环境验证

验证的目标不是“打进去”，而是回答“在这套版本与配置组合下，修复前后是否存在可观察的行为差异”。因此优先在隔离环境进行：克隆同版本内核与同发行版的测试机，放在独立虚拟网络里，只保留必要的监听服务，测试前打快照，测试后销毁。

验证手段按影响从低到高排列：

1. 只读核对。确认内核版本落在受影响区间、确认修复包未安装、确认目标端口可达、确认相关内核配置。这一步不发送任何异常流量，适合生产环境。
2. 合成流量观察。在隔离环境中向测试服务发送符合协议规范的握手流量，观察内核日志、连接状态和服务可用性是否出现异常。即便在隔离环境，也应预设停止条件：出现内核告警、服务不可用或节点失联时立即停止并回滚快照。
3. 差分验证。在同一个隔离环境中，分别用修复前和修复后的内核执行同一组测试，比较行为差异。差分结果比单次“是否崩溃”更有说服力，也更适合写进报告。

不建议在生产环境做第 2、3 类操作。如果授权范围不允许任何主动验证，就停在第一步，并在报告中明确标注“可利用性未独立验证”，同时给出基于暴露面的风险排序。这不是回避，而是把不确定性如实交付。

第四步：证据记录与报告字段

证据要能让另一位工程师在不询问你的情况下复核结论。建议至少保留以下字段：

结论字段要避免“存在高危漏洞”这类无法复核的表述，改成“运行内核 5.15.0-xx 未包含修复，443/TCP 对公网可达，隔离环境差分验证显示修复前后行为存在差异”。把事实和推断分开写，后续整改才有依据。

第五步：补丁确认

补丁确认不是“执行了 update 就算完成”。发行版公告给出的修复包版本才是判断基准：Ubuntu 的修复进入 -proposed 口袋后需要按公告启用并验证，Amazon Linux 2 与 Amazon Linux 2023 已发布对应内核包并要求更新后重启，RHEL 系在公开信息中一度标记为延期，具体状态必须以厂商公告为准。修复包安装后，按下面顺序确认：

# 1. 确认修复包已安装
dpkg -l 'linux-image*' | grep ^ii        # 或 rpm -qa 'kernel*'
# 2. 确认运行内核已切换到修复版本
uname -r
# 3. 确认默认引导条目指向修复版本
# GRUB 环境可用 grubby --default-kernel 或检查 /boot/grub2/grubenv
# 4. 重启后复核服务与监听端口
systemctl --failed
ss -lntp

需要特别注意的是“包已装、未重启”这一状态。它会让资产在清单上显示为已修复，实际运行内核仍是旧的。报告里应把“安装状态”和“生效状态”分开记录。使用 kexec 或 livepatch 的环境，还要确认修复是否真正覆盖该代码路径，而不是只更新了包元数据。

第六步：回滚预案

内核更新是少数“改完必须能退回去”的操作。回滚预案应在变更前写好，而不是在业务异常时临时讨论。

保留旧内核包和可引导条目是最低成本的手段。多数发行版默认保留上一版本内核，但要确认引导菜单中确实存在该条目、默认启动项未被覆盖、/boot 空间足够。云主机还应确认控制台或串口访问可用，避免网络栈异常时无法登录。对关键业务，建议在变更前打快照或镜像，并记录快照 ID 与创建时间。

回滚触发条件要提前量化，例如：更新后核心接口错误率超过阈值、关键服务无法启动、出现与网络相关的内核告警、或业务方在观察窗口内确认功能异常。回滚步骤应写成可执行清单：切回旧引导条目、重启、复核 uname -r、复核服务与端口、通知相关方、记录回滚原因。回滚完成后，资产重新处于未修复状态，此时需要补偿控制，例如收紧安全组、限制 IPv4 TCP 暴露面、增加流量监测，并把再次修补排入下一个窗口。补偿控制只能降低暴露，不能替代补丁，这一点要在报告里写清楚。

复测与收口

复测要回到最初那条假设，逐项确认：运行内核是否已包含修复、修复包版本是否与厂商公告一致、重启是否已生效、暴露面是否仍与清点时一致、隔离环境中的差分结果是否消失。复测通过后，更新资产清单中的内核基线和补丁状态，把本次使用的验证方法、证据位置和回滚记录归档，供下一次同类漏洞排查复用。

对仍未修复的资产，不要用“已通知”作为收口。给出明确的到期时间、补偿控制措施和责任人，并把它们作为遗留风险记录在案。CVE-2026-98432 的教训不在于评分有多高，而在于它的触发面落在每个暴露 IPv4 TCP 端口的主机上：版本、配置、可达性三者同时成立才构成真实风险，而这三项恰好都可以通过授权、可复核的方式逐台确认。把这条链路固化成流程，比记住一个编号更有用。