# CVE-2026-98432：当等待内核修复成为一个问题时

自 Ubuntu 于 10 月 15 发布其 CVE-2026-98432 条目以来，已经过去了 19 天。对于运营面向互联网服务的团队来说，等待时间太长且令人担忧。

我们自己的干预于 10 月 30 开始，采取了临时措施。四天后，11 月 3，我们在两个 VPS 实例上安装了官方修复程序，并验证它们已启动到内核 7.0.0-43-generic。

这些 Ubuntu 包来自建议的测试包。 Ubuntu 宣布的一般资格仍在进行中：我们经过验证的安装不会将这些软件包转换为已通过通常的稳定渠道分发的更新。

## 为什么等待很重要

应用程序不断响应。其证书有效。部署成功。这些结果都没有表明接收网络连接的内核中的缺陷已得到修复。服务可能看起来完全正常，但安全响应仍未完成。

对于管理员来说，每增加一天就意味着维持临时决定、遵循公告并准备干预。那段时期是我们所关心的。它既不支持毫无根据的疏忽指控，也不支持临时措施因疏忽而成为永久性措施。

## 修复方案已存在，但其分发渠道很重要

11 月 2 发布的 Ubuntu 公告描述了针对多个受支持版本的拟议测试包中的修复。对于 Ubuntu 26.04 LTS 和 linux 软件包，其命名版本为 7.0.0-43.43. 该公告称，更新将在测试后发布，但没有给出具体日期。

这改变了描述情况的方式。说不存在修复是不准确的。说每个 Ubuntu VPS 都已经打了补丁同样是不准确的。正在测试的软件包、其通过通常的更新渠道的可用性及其在计算机上的实际使用是不同的事实。

[Ubuntu 公告于 2 11 月发布](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432)

## - 提议仍需做出生产决定

Canonical 将早期访问提议的内核描述为能够执行自己的验收测试的团队的选择。这个渠道可以让这项工作更快开始。它并不表明更广泛的资格认证过程已经完成。

在为实际应用程序提供服务的 VPS 上，该决策还涉及重新启动、驱动程序、网络和恢复。在不检查所选软件包的情况下广泛启用存储库和升级可能会将干预范围扩大到预期修复之外。因此，本文不提供将生产机器切换到-proposal 的通用命令。

有用的问题不仅仅是是否有可用的修复程序。它是哪个渠道提供的，针对哪个发行版和内核风格，以及经过什么验证。

[尽早访问建议的内核](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy)

## 两个 VPS 实例都运行修补后的内核

TinyDigit VPS 从 7.0.0-38-generic 迁移到 7.0.0-43-generic。 PRNext VPS 从 7.0.0-28-通用移动到 7.0.0-43-通用。在每台服务器上，我们安装了四个 Ubuntu 版本 7.0.0-43.43 的内核包，然后在重新启动后检查实际运行的内核。

安装仅限于这些软件包，没有发行版升级或全局启用。以前的内核仍然可用作启动回退。在此后续过程中，临时网络过滤和 MPTCP 设置也将保留。

重新启动后，我们打开到每台服务器的新 SSH 连接，并检查来自测试的 PRNext 和 TinyDigit 端点的 HTTPS 响应。五个原始应用程序容器已存在并准备就绪；他们的五个本地别名也通过 HTTPS 进行响应。

外部依赖仍然不可用；完整的应用程序恢复仍需要验证。

## 检查实际运行的内核

安装在磁盘上的内核包可能与当前正在执行的内核不同。干预后，检查需要涵盖正在运行的系统、新的 SSH 访问、HTTPS 及其托管的应用程序。成功的包管理器退出不足以结束工作。

这些命令不会修改服务器。它们提供了与该发行版的官方跟踪器进行比较的起点。仅凭版本号，如果没有包标识和发行版的向后移植修复程序，无法确定结果。

```bash
uname -r
cat /etc/os-release
```

## 缓解措施不是内核修复

我们的原始指南记录了 10 月 30 采取的临时措施以及随后进行的检查。它仍然是历史记录，而不是每个 VPS 实例当前状态的证据。

禁用 MPTCP 并不能修复根本缺陷。 Ubuntu 的跟踪器还描述了针对目标 IPv4 选项过滤的限制。加载的规则、数据包计数器或可访问的网站并不能保证针对所有利用路径的保护。

[原版指南](/zh/blog/cve-2026-98432-ubuntu-vps-mitigation)

## 有用的安全更新应该告诉您什么

可以合理地期望对已修复的内容、仍在测试的内容以及机器本身仍有待完成的内容进行清晰的说明。同样重要的是要认识到在没有充分验证的情况下部署内核更新的成本。紧迫性和稳定性属于同一个决定。

我们的立场很简单：临时措施必须在仍然需要做的工作中保持可见。端点应该是实际运行经过验证的服务的修补版本，而不仅仅是令人放心的公告。 npm 对 PRNext 的更新无法执行 Linux 系统任务。

## Sources

[Ubuntu · CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432)

[Ubuntu · Fixes available in -proposed, 2 November 2026](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432)

[Canonical · Kernel release strategy](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy)

[Ubuntu · SRU verification](https://ubuntu.com/project/docs/SRU/reference/sru-verification/)

已发表: 2026-11-03

修改的: 2026-11-03

作者: PRNext

---

语言: zh-Hans

Canonical: https://prnext.dev/zh/blog/cve-2026-98432-ubuntu-waiting-for-kernel-fix

Index: https://prnext.dev/llms.txt