摘要
2026 年 11 月 3 日，我的三台服务器收到一个不太常见的通知：Ubuntu 内核存在一个高危漏洞 CVE-2026-98432，官方跟踪页上 24.04 的状态还是 Vulnerable、修复进行中，没有可用的修复内核。等补丁是常规做法，但“等”本身也是一个需要管理的状态：漏洞暴露在那里，每多等一天就多一天窗口。这篇文章记录我当时的做法——不用补丁，而是用一条 sysctl 把用不到的 MPTCP 协议面关掉，先把可达的攻击面收起来，再用每周一次的盯梢等官方修复内核落地，最后升级、重启、撤销缓解。整套做法没有高深之处，关键在三点：先确认自己真的受影响，再确认缓解真的生效，最后给缓解设一个明确的退出条件。
一、漏洞来了但没有补丁：先看清自己处在什么位置
CVE-2026-98432 是 Ubuntu 内核 TCP/ip_options 相关的一个 UAF（释放后使用）漏洞，评级为 High。UAF 这类漏洞的麻烦在于，它发生在内核处理网络数据包的路径上，一旦可达，影响的就不是某个应用，而是整台机器。
发现漏洞后的第一件事不是动手，而是先看官方跟踪页，确认三件事：
第一，这个漏洞影响我正在用的版本吗？我手里的三台机器都是 Ubuntu 24.04。官方跟踪页上，24.04 的 linux 内核包状态是 Vulnerable，修复工作正在进行中（work in progress in 6.8.0-149.149）；linux-hwe-6.17 同样是 Vulnerable；Oracle 内核 linux-oracle 也是 Vulnerable，修复进行中（work in progress in 6.8.0-1067.71）。也就是说，我用的版本全在影响范围内，而且没有任何一个包的状态是 Released 或 Fixed。
第二，有没有临时变通办法？官方跟踪页没有给出已发布的修复内核，常规的 apt upgrade 升不到任何东西。这个状态很关键：它决定了接下来不是“打补丁”，而是“做缓解”。
第三，这个漏洞的触发需要什么条件？CVE 的描述指向内核 TCP 协议栈里与 MPTCP（多路径 TCP）相关的代码路径。MPTCP 是一项让一条 TCP 连接同时走多条子路径的技术，主要用在移动设备多网卡切换这类场景。我的服务器都是固定线路的云主机，没有任何服务依赖 MPTCP 做多路径传输——这意味着，关掉 MPTCP 对我几乎没有业务代价，而它正好是漏洞所在的协议面。
这三点确认完，决策就清楚了：补丁还没来，先把 MPTCP 关掉，把漏洞的可达路径断掉；同时把“等补丁”变成一个有检查、有通知的正式流程，而不是凭记忆惦记。
二、没有补丁时的缓解思路：关掉用不到的协议面
内核漏洞的缓解有几种常见路子：升级内核（没补丁，此路不通）、用防火墙挡特定流量（TCP 选项层面的问题，防火墙规则很难精准拦截）、关掉相关功能（可行，且代价可控）。我选了第三种。
MPTCP 在 Linux 内核里由一个开关控制：
net.mptcp.enabled
把它设为 0，内核就不再创建 MPTCP 套接字、不再走 MPTCP 的代码路径。漏洞所在的 TCP/ip_options 处理逻辑与 MPTCP 的交互面随之关闭，攻击者即使能向服务器发包，也到不了那段有问题的代码。
这个做法成立的前提，是“关掉的东西确实没人用”。我在动手前先确认了三台机器上跑的服务：反向代理、容器里的应用服务、监控 agent、备份脚本，全部走普通 TCP，没有任何一个服务配置过 MPTCP，也没有任何客户端要求多路径连接。对我来说，MPTCP 是内核默认带上、但从来没人调用的功能——关掉它，等于关掉一扇从来没开过的门。
但“没人用”不能只凭印象，需要一个可以复查的证据链：执行前记录各服务的运行状态，执行后逐台验证开关确实为 0、关键服务仍然正常。这个验证步骤写在下面第三节。
持久化同样重要。只在命令行敲一次 sysctl -w，重启后就失效了，缓解会悄悄消失，而漏洞还在。所以缓解必须写进 sysctl 的持久配置文件，重启后依然生效：

/etc/sysctl.d/99-mptcp.conf

net.mptcp.enabled=0
文件名里的 99 是刻意选的：sysctl.d 目录按字典序加载，99 开头的文件最后加载，不容易被发行版自带的其他配置文件覆盖掉这条设置。
三、三台机器逐台执行与复查
三台机器分别是 Oracle 首尔的一台、华为云香港的一台和腾讯云的一台，系统都是 Ubuntu 24.04。执行过程完全相同，逐台做、逐台验，不批量操作——批量操作一旦某台出问题，很难分清是哪一步、哪台机器的问题。
每台机器上的操作只有三步：

1. 立即生效

sudo sysctl -w net.mptcp.enabled=0

2. 写入持久配置，重启后依然生效

echo “net.mptcp.enabled=0” | sudo tee /etc/sysctl.d/99-mptcp.conf

3. 验证：确认开关确实为 0

sysctl net.mptcp.enabled

期望输出：net.mptcp.enabled = 0

第三步的输出必须亲眼看到 = 0，而不是假设前两步没报错就等于成功。写配置文件时如果路径敲错、权限不对，tee 会报错；sysctl -w 如果内核不支持该参数，也会直接报错。这些错误都可能被批量脚本吞掉，逐台人工确认是最稳妥的办法。
验证完开关，再验证服务。我的检查清单很短，但每台都跑一遍：
反向代理是否正常响应，首页和几个关键子服务能否打开；
容器里的应用是否还在运行，有没有因为网络栈变化而异常退出；
监控 agent 是否在线，面板上三台机器是否都显示正常；
备份任务的最近一次运行记录是否正常。
三台机器全部通过：开关为 0，关键服务无异常。这个结果符合预期——MPTCP 本来就没人用，关掉它不应该影响任何现有服务；如果哪台机器的服务在关掉之后出现异常，那反而说明这台机器上有未被发现的 MPTCP 依赖，需要先停下来排查，而不是继续往下做。
第二天新加入的一台新加坡机器，在入网当天也按同一套流程执行了相同的缓解：写入同一个配置文件、验证开关为 0、复查服务正常。新机器直接继承这条政策，而不是等它“以后再说”——缓解措施最怕的就是新机器漏网，fleet 里留一台没关的，等于整个缓解白做一半。
四、暴露面核查：确认关掉的是正确的东西
关掉 MPTCP 之后，我又做了一次暴露面核查，目的是确认两件事：缓解确实覆盖了漏洞的入口，以及没有其他同类入口被漏掉。
第一，确认 MPTCP 真的关掉了。除了看 sysctl net.mptcp.enabled 的返回值，还要确认没有进程正在使用 MPTCP 套接字。检查方法是看当前所有 TCP 监听和连接里有没有走 MPTCP 的——正常情况下，服务器上的监听端口应该全部是普通 TCP。如果发现某个服务确实在监听 MPTCP 端口，那就说明“没人用 MPTCP”这个前提是错的，需要回头处理那个服务，而不是假装缓解已经完成。
第二，确认漏洞的触发面确实收窄了。CVE-2026-98432 的问题出在内核处理 TCP 选项的代码路径上，而 MPTCP 的握手和选项协商会走到这段逻辑。关掉 MPTCP 之后，外部发来的 MPTCP 握手包不会再触发内核创建 MPTCP 连接，也就到不了有问题的代码分支。这不是“修好了漏洞”，而是“让漏洞够不着”——两者有本质区别，写进记录里时要说清楚，不能把缓解写成修复。
第三，确认没有为了缓解引入新的问题。sysctl 的改动只动了 MPTCP 一个开关，没有碰其他网络参数；持久化文件里也只有这一行，没有顺手加别的“优化”。缓解期间保持改动最小，是为了之后撤销时同样简单：删一个文件、重启一次，就回到原来的状态。
这个核查做完，我才把这次缓解标记为“已完成”。在此之前，它的状态一直是“已执行、待验证”，而不是“已解决”。
五、盯梢补丁：缓解不是终点，要设退出条件
缓解措施最大的风险，是被人遗忘。关掉 MPTCP 之后，服务器照常运行，漏洞不再是每天看得见的问题，三个月后可能没人记得这台机器上还有一个临时缓解措施，更没人记得它当初是为什么加的。所以缓解落地当天，我就给它设了两个东西：一个盯梢任务，和一个明确的退出条件。
盯梢任务是一个每周一次的定时检查，每周一上午去看 Ubuntu 官方跟踪页上 24.04 几个内核包的状态。检查只关心一个问题：有没有 Released 或 Fixed 的修复内核。没有，就静默，什么都不发，下周再来；有了，才通知我。
这个“没有就不发”的设计是刻意的。盯梢类任务如果每周都发一条“还没补丁”，很快就会变成没人看的噪音，真正有补丁的那天反而容易被淹没。静默不是偷懒，是为了让通知只在需要做决定的那天响起。
退出条件同样在第一天就写好了，触发之后按顺序做三件事：
升级到官方修复内核；
重启机器，让新内核生效；
删除 /etc/sysctl.d/99-mptcp.conf，撤销缓解。
第三步最容易被漏掉，但同样重要。缓解措施是临时手段，补丁落地后继续留着它，等于在系统里留了一个没人记得原因的特殊配置。以后排查网络问题时，这个文件会成为一个干扰项；更糟的是，如果将来某个服务真的需要 MPTCP，这个被遗忘的开关会让排查走很远的弯路。撤销缓解和打补丁一样，都是这次应急的正式收尾动作。
截至写稿时，官方跟踪页最后一次更新还是 10 月 30 日的状态，24.04 的几个内核包仍然没有修复版本，盯梢继续静默。这个状态本身也是信息：它说明从漏洞公开到修复内核发布之间存在一个真实的时间窗口，而这个窗口正是缓解措施存在的意义。
总结
这次应急可以浓缩成五句话：先看官方跟踪页，确认自己在影响范围内、且确实没有修复内核；再确认漏洞所在的协议面是不是自己用不到的功能，是，才有关掉它的资格；执行时逐台做、逐台验，开关值和服务状态都要亲眼确认；执行完做一次暴露面核查，确认缓解真的覆盖了入口、没有漏网的新机器；最后给缓解设一个盯梢任务和退出条件，补丁一到就升级、重启、撤销。
内核漏洞最考验人的地方，不在于技术难度，而在于时间差：从漏洞公开到修复内核发布之间，总有一段什么都没有的窗口。这段窗口里能做的事不多，但“关掉用不到的协议面”是最划算的一件——代价是一条配置，收益是把攻击面实实在在地收小一圈。更重要的是，缓解从一开始就要带着退出条件落地，否则它会在系统里从临时措施慢慢变成无人知晓的永久配置，而那本身就是下一次故障的伏笔。