CVE-2026-98432 内核漏洞处置：WordPress VPS 的 Ubuntu 补丁通道核查、nftables 临时缓解与重启验收

CVE-2026-98432 是一个影响 linux 内核 IPv4 TCP 栈的释放后使用（use-after-free）漏洞，公开资料给出的 CVSS 评分为 9.8，影响范围从 linux 4.4 起的内核。它出问题的位置在网络栈而不是某个应用，因此一台面向公网提供 WordPress 的 VPS，只要接受 IPv4 TCP 入站连接，就在暴露面之内；而 Nginx、PHP-FPM、MySQL、SSH、监控探针、备份任务，以及可能存在的 Go 1.24+ 服务，都是需要逐一验证的业务路径。需要先厘清一点：MPTCP 不是暴露的必要条件，普通 TCP 连接同样可以走到有问题的代码路径，把关闭 MPTCP 当作修复是错误判断。

这篇文章按四步展开：核对内核包和 Ubuntu 补丁通道、用 nftables 做有边界的小范围缓解、安排重启窗口并逐项验收、准备好回滚路径。受影响版本、修复状态和利用条件以官方公告与发行版说明为准，本文给出的是可复核的检查方法和变更顺序。

第一步：把运行内核、安装包和通道状态分开核对

不要只看 uname -r 就下结论。运行内核、已安装的内核包、软件源里可用的候选版本，是三件不同的事，必须分别记录。

在 VPS 上以具备 sudo 权限的账号执行：

uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2, $3}'
apt-cache policy linux-image-generic
apt-cache madison linux-image-generic | head

预期现象是：uname -r 显示当前运行版本；dpkg -l 列出已安装的内核包及其版本；apt-cache policy 的 Candidate 指向某个软件源。重点看 Candidate 来自 -updates、-security 还是 -proposed。如果 /etc/apt/sources.list.d/ 下启用了 -proposed，要把这个事实单独标注出来，因为它意味着候选版本可能来自预发布通道。

接着到 Ubuntu 的 CVE 追踪页核对具体 release 与内核 flavor。Ubuntu 的 linux 包按发行版、按 flavor（generic、oracle、aws、gcp 等）分行列出状态，不能只看 generic 一行就推断所有 VPS 镜像。实际部署中，云厂商镜像常用的是带 flavor 的内核包。

把核对结果归入下面三类，处理动作完全不同：

这里有两个常见误判。第一，把追踪页的“work in progress”当成“已有修复”，实际上它只表示有人在处理。第二，看到某个第三方帖子说“已经更新”，就直接在生产执行 apt install，而没有确认候选版本来自哪个通道。Ubuntu 的修复会按 release 和 flavor 分批推进，不同 VPS 镜像的节奏并不一致，必须以本机 apt-cache policy 和官方追踪页为准。

如果确认修复包已进入正式通道，更新时建议只升级内核相关包，避免顺带引入无关变更：

sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-headers-generic

如果使用的是云厂商 flavor，把包名换成对应的 linux-image-<flavor>。执行后不要立即重启，先确认新内核已安装、GRUB 已生成对应条目，再进入第三步的窗口安排。

第二步：nftables 临时缓解的适用边界

在修复包尚未进入正式通道时，可以用 nftables 丢弃带 IP 选项的 IPv4 TCP SYN 包，降低被触发的概率。原理很直接：漏洞与 TCP 连接请求处理中 IP option 内存的释放时序有关，把携带 IP options 的入站 SYN 挡在主机边界外，能减少走到该路径的机会。公开测试资料显示，规则加载后普通 TCP 连接仍然成功，而 SYN 携带 IP options 的连接会超时；Red Hat 也明确说明这类过滤只能降低暴露，不能完全防止利用。

这意味着它是缓解，不是修复。不要把它写进变更单的“已修复”栏，也不要用它替代内核更新。

先建独立的 table 和链，避免和现有防火墙规则混在一起难以回滚：

sudo nft add table ip cve98432
sudo nft add chain ip cve98432 input '{ type filter hook input priority -10; policy accept; }'

先只计数、不丢弃，观察一段时间：

sudo nft add rule ip cve98432 input ip protocol tcp ip hdrlength != 5 tcp flags syn counter
sudo nft list table ip cve98432

ip hdrlength != 5 匹配的是 IPv4 头长度大于最小 20 字节、即携带 IP options 的包；配合 tcp flags syn 只处理建连请求。计数器增长说明网络里确实存在这类流量。确认没有合法业务依赖 IP options 后，再把计数规则改为丢弃：

sudo nft delete rule ip cve98432 input handle <handle号>
sudo nft add rule ip cve98432 input ip protocol tcp ip hdrlength != 5 tcp flags syn counter drop

执行位置是 VPS 本机，priority -10 让它在常规过滤之前生效。需要评估的影响面如下：

• HTTP/HTTPS：普通浏览器和 CDN 回源一般不带 IP options，Nginx 访问日志和状态码应无变化；如果前面有某些老式负载均衡或健康检查带 options，需要单独确认。
• SSH：日常登录不受影响。建议在变更时保留一个已建立的 SSH 会话，另开一个新会话验证，避免把自己锁在外面。
• 监控：Prometheus node_exporter、黑盒探针等如果走普通 TCP，不受影响；若探针构造特殊包，需要观察探针成功率。
• Go 1.24+ 服务：如果服务显式启用了 MPTCP 或对 IP options 有依赖，要单独测试；不要假设所有 Go 服务行为一致。
• IPv6：该规则只处理 IPv4，IPv6 路径不在覆盖范围内，不要误以为已全面缓解。

验证时准备两类检查：普通连接应成功，例如 curl -I https://你的域名 和对 SSH 端口做一次新连接；带 IP options 的 SYN 应超时。后者涉及构造数据包，只应在你拥有授权的测试环境中进行，不要在第三方系统上尝试。若没有条件构造，至少确认计数器在增长、业务探针全部正常，并把“未验证带 options 路径”写进变更记录。

回滚很简单：

sudo nft delete table ip cve98432

删除后规则立即消失，不需要重启。把这条命令和变更单放在一起，确保值班人员能找到。

第三步：重启窗口与逐项验收

内核更新只有重启进入新内核才真正生效。对 WordPress VPS 来说，重启窗口要覆盖数据库连接、PHP 进程、Nginx 上游和备份任务，不能只看网站首页是否打开。

重启前完成四件事：

1. 记录当前运行内核 uname -r 和已安装内核包版本，写入变更单。
2. 确认新内核已安装、GRUB 中存在对应启动项，并保留至少一个旧内核可回退。
3. 完成一次数据库和站点文件的可用备份，确认备份可读，而不只是“任务成功”。
4. 暂停或错开正在运行的备份、抓取、图片处理等长任务，避免重启中途留下半成品。

重启后按下面清单逐项确认：

观察窗口建议至少覆盖一个完整的业务低峰到高峰周期。重点看四类信号：dmesg 是否出现新的内核告警；Nginx 的 5xx 和上游超时是否上升；SSH 新连接是否变慢或失败；监控探针是否出现规律性断点。如果更新前启用了 nftables 缓解规则，重启后要确认规则仍在、计数器行为符合预期，或者按计划移除。

回滚路径要提前写清楚，而不是出事再找：

• 如果新内核启动后业务异常，先在 GRUB 中选择旧内核启动，确认站点恢复，再排查新内核与驱动、云厂商 agent、文件系统的兼容性。
• 如果只是 nftables 规则导致连接异常，删除对应 table 即可，不需要重启。
• 不建议在生产直接降级内核包；优先通过启动旧内核恢复服务，保留现场后再决定后续动作。

第四步：把这次处置变成可复用的检查项

做完一轮之后，至少留下三样东西：一份记录运行内核、包版本、通道来源和重启时间的变更单；一份 nftables 缓解规则的启用与移除记录，注明它只是临时措施；一份重启后的验收结果，包含失败项和回滚动作。下次遇到同类内核 CVE，可以直接复用这套顺序：先分清运行内核、安装包和通道状态，再决定是更新、观察还是临时缓解，最后用业务路径验收而不是只看服务是否启动。

还有两点需要持续跟踪。第一，Ubuntu 的修复会按 release 和 flavor 分批推进，今天在 -proposed 不代表明天还在，今天没修复也不代表明天没有，复查时要重新看追踪页和 apt-cache policy，不要凭上一次的结论操作。第二，公开的 PoC 和利用细节会改变风险判断，但在自己的环境中做任何验证都必须限定在授权范围内，不要对生产入口做压力式测试。临时规则能争取时间，真正关闭这个问题仍然要回到厂商内核包和一次经过验收的重启。