CVE-2026-98432 缓解工具包

IPv4 TCP inet_opt/ireq_opt 释放后使用（上游修复 e3f33b0a， 在 inet_sock_destruct() + tcp_v4_reqsk_destructor() 中将 kfree → kfree_rcu）。 触发条件：客户端 SYN 携带 IPv4 选项（ihl > 5）——不带选项时， 被竞争的 ireq_opt 对象永远不会被分配。所声称的远程 root 利用还需要一个 MPTCP 监听器。

文件

文件	需要 root	用途
cve-audit.sh	否	只读的暴露面 + 可修补性报告
cve-mitigate.sh	应用/撤销	通过 nft 丢弃带 IP 选项的 SYN，可选关闭 MPTCP
nft-rules.txt	—	独立规则集（nft -f nft-rules.txt）
cve-detect.sh	捕获模式	针对该利用数据包特征的 tcpdump 传感器
kpatch-el-build.sh	构建/安装	面向 EL 系列的经过验证的 kpatch/livepatch 构建器
klp-handcraft-build.sh	构建/加载	为无法运行 kpatch-build 的 IBT 内核（EL10）手写的 klp 模块
patches/CVE-2026-98432.patch	—	上游修复，可直接用于 kpatch-build
tests/run-tests.sh	否	测试框架（netns 规则集加载 + 打桩构建器端到端测试）

事件快速上手

./cve-audit.sh                                # where do I stand?
./cve-mitigate.sh apply --with-mptcp-off      # closes trigger + claimed root path
./cve-detect.sh count 30                      # anyone probing with IP options?
sudo ./kpatch-el-build.sh --name CVE-2026-98432 \
     --expect inet_sock_destruct,tcp_v4_reqsk_destructor \
     [--sign priv.pem cert.pem] [--install] \
     patches/CVE-2026-98432.patch
# verify: cat /sys/kernel/livepatch/CVE-2026-98432/enabled  -> 1
./cve-mitigate.sh status                      # keep until 100% patched, then:
./cve-mitigate.sh undo

EL 矩阵

目标	说明
EL7 (3.10)	不受影响（触发代码在 4.4 才引入）；构建器仍可用于其他补丁
EL7h/EL8 (4.18)	受影响；kernel-debuginfo 提供 /usr/src/debug/kernel-*/linux-*；kpatch-build 来自 EPEL
EL9 (5.14)	受影响；内核使用 gcc-toolset 构建——构建器会自动前置匹配的 /opt/rh/gcc-toolset-*
EL10 (6.12)	IBT：kpatch-build 0.9.11 拒绝 CONFIG_X86_KERNEL_IBT=y 的内核（dynup/kpatch#1320）——请使用 klp-handcraft-build.sh；在 Secure Boot/lockdown 下强制模块签名
CloudLinux 8/9/10	发行版 id 不在 kpatch-build 的支持列表中，因此构建器始终显式传入 -s/-c/-v；debuginfo 来自与 rpm -qf /boot/vmlinuz-$(uname -r) 匹配的 AlmaLinux/CentOS kernel-debuginfo

RHEL 上的 debuginfo 需要启用相关仓库，例如 dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) （在未计费主机上使用 subscription-manager repos --enable=rhel-9-appstream-rpms 等）。

构建器在加载任何内容前会验证什么

1. 运行配置中存在 CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y。
2. 目标内核 == 运行内核（vermagic 墙），kernel-devel/debuginfo/vmlinux 存在。
3. 补丁正向应用；如果它反向应用，则会告知你内核 已包含该修复（kpatch 稍后会以“no functional changes”失败）。
4. 编译器与内核构建所用的 gcc 匹配（.comment 级检查委托给 kpatch-build；toolset 查找在此处完成）。
5. 构建后：vermagic，以及变更函数的严格双向允许列表 （--expect）——出现意外的第三个变更对象即为硬失败。
6. 可选的 sign-file 使用你的密钥对 + modinfo sig_type 复查； 通过 MOK 注册证书以支持 Secure Boot。
7. --install 放入 /var/lib/kpatch/$(uname -r)/，通过 kpatch/insmod 加载，启用 kpatch.service 以实现重启后持久化。

金丝雀运行手册（在集群推广前执行）

1. 金丝雀 VM，uname -r 与集群相同。
2. ./kpatch-el-build.sh ... --install；确认 /sys/kernel/livepatch/<name>/enabled == 1。
3. 竞态压力测试：从第二台机器，hping3 -S -p <port> --tcp-opts ... 洪泛 攻击监听端口，同时在金丝雀上切换 net.ipv4.tcp_migrate_req=1； 在 ip_options_build() 内部注入人工 udelay() 的 KASAN 内核变体 应在没有补丁时复现 UAF，在有补丁时保持静默。
4. 观察 uname -r 未变（livepatch 不会提升它）、kpatch list、 dmesg -w 中的 taint 和 klp 转换停滞 （/sys/kernel/livepatch/<name>/transition 必须归零）。
5. 推广集群；在 100% 覆盖后 24–48 小时移除 nft 规则。
6. 无论如何在下一个窗口重启回厂商内核——livepatch 在内核升级时堆叠效果很差。

状态 / 诚实说明

测试框架：所有检查在 AlmaLinux 10.2 VM（内核 6.12.0-211.64.1.el10_2）上通过。 真实的 nft 规则集在全新的 netns 中加载并列出；pcap 过滤器 针对实时 tcpdump 编译；构建器流水线针对 带有真实 .ko 夹具和注入符号源的桩 kpatch-build 进行了端到端演练。

在该 EL10 虚拟机上已验证可用：

• klp-handcraft-build.sh --load 构建并启用了一个 livepatch： /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1，transition 已排空， sysfs 列出 inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1；正常 TCP（HTTP 200）不受影响。未签名的 .ko 会使内核被污染（taint）；Secure Boot lockdown 会拒绝加载它（该虚拟机以未签名模式运行）。
• 真实的 kpatch-build（dynup 0.9.11，从源码构建）在 EL10 上硬性失败， 报错 "kernel option CONFIG_X86_KERNEL_IBT not supported" —— 构建器 现在会对此做预检，并指向手工构建路线。真正的二进制差分 kpatch-build 运行在 EL8/EL9 上仍未经过验证。
• 缓解措施已生效：线上 20 个 scapy option-SYN 被防护规则计数并丢弃； 3 个普通 SYN 通过；ssh 不受影响。
• 现场发现：在 EL10 6.12.0-211 上，带 IP options 的构造 SYN 会命中 nft prerouting raw hook（-300），但永远不会到达 INPUT hook（开放 端口、lo 以及干净的 netns 均可复现；没有 kfree_skb tracepoint 事件， 尽管 SELinux 阻止了 perf/kprobes 且 tcpdump 未捕获到任何内容，因此 确切的丢弃函数尚未确定）。因此缓解链挂接在 prerouting priority raw，它能够观测并丢弃这些包；朋友在 prerouting priority -310 的规则出于同样的原因也能生效。 在将其用于真实事件之前，请先在你的 EL 金丝雀上运行一次正常路径。