Linux 官方于 2026 年 10 月 3 日发布稳定版 7.2.9。对于维护 Linux 网络节点的团队，这次更新里值得细看的，是 net/sched/act_ct.c 中两项连接跟踪修复：一项调整 helper 的调用顺序，另一项避免修改被多个报文共享、尚未确认的连接条目。
两项补丁都涉及释放后使用（use-after-free，简称 UAF）。问题落在特定网络处理路径，不能据此认定所有 Linux 服务器都受影响，也不能推断已有攻击发生。运维上真正需要做的，是确认自己的内核是否包含修复，以及业务是否使用相关功能。
从稳定版更新，找到需要关注的网络路径
tc 是 Linux 流量控制体系的用户空间入口。它可以通过过滤器和动作组合处理报文，ct 动作则把连接跟踪引入这条处理链。连接跟踪用于维护连接状态，也能与 NAT、连接标记和标签等机制配合。
本文讨论的是 tc ct 对应的 act_ct 实现，不是对所有防火墙或所有容器网络的笼统判断。节点部署了容器、运行了虚拟交换机，或者加载了 conntrack 模块，都不足以单独证明它经过这条路径。实际规则、网络后端和内核版本需要一起核对。
还要区分两个日期：这两项上游提交的合入时间是 9 月 24 日，本文的近期动态是它们进入 10 月 3 日发布的 7.2.9 稳定版更新。稳定分支会回移已有修复，并非每项补丁都在发布当天首次出现。
第一项修复：先完成扩展，再调用 helper
连接跟踪条目可以附带扩展数据。某些协议的 helper 会维护预期连接（expectation）信息；上游补丁说明指出，helper 执行时会把扩展区中的指针关联到 expectation 列表。
如果连接尚未确认，后续处理还可能增加扩展。扩展区一旦重新分配，列表里保存的旧指针就可能失效，而删除 expectation 时仍可能访问它。这便形成了 UAF 风险。
补丁没有靠多加一次空指针判断来处理问题，而是改变处理顺序：将 helper 调用移到其他扩展添加完成之后。按这个补丁所处理的路径，可以概括为：
- 设置连接标记、标签并添加所需扩展。
- 再执行 helper，让它引用已经完成扩展添加的数据。
- 继续后续的连接提交处理。
这项调整也有行为细节：helper 拒绝报文时，标记和标签可能已经设置。提交说明明确提到，这个 API 本来就不承诺整组操作具有原子性。测试时不能假设“最后报错”意味着前面的状态修改全部回滚。
第二项修复：共享条目不能只靠调整顺序
顺序修复解决了同一次处理中的问题，但报文克隆后还可能出现另一种情况：多个报文引用同一份尚未确认的连接跟踪条目。
补丁说明给出的过程是，第一份报文在提交过程中运行 helper，建立对扩展区的引用，但连接未能完成确认；另一份报文随后处理标签或 NAT，新增扩展并触发扩展区重分配。先前建立的引用仍可能因此失效。
对应修复会在命中缓存连接、准备执行 commit 或 NAT 时，检查条目是否同时满足“未确认”和“共享”。满足条件时，先重置当前报文附带的连接跟踪引用，再重新进入相应处理路径。这里不是清空整台节点的连接跟踪表。
为什么检查条件里要单独包括 NAT？上游说明指出，act_ct 允许在不带 commit 的情况下执行 NAT。直接取消这种用法会改变用户空间接口，所以修复需要覆盖 NAT 引发扩展变化的情况，而不能只盯着提交动作。
这两项补丁放在一起，能看出内核维护中的一个难点：对象在一条调用链内使用正确，不代表它被多条路径共享时也安全。调用顺序和对象生命周期必须一起处理。
对网络节点的影响，先核对补丁再判断
官方变更记录足以确认问题机制和修复方向，但本文引用的资料不支持“已遭利用”“可以远程接管所有节点”之类结论。这里也不据此猜测 CVE 编号或漏洞评分。
对于使用相关路径的节点，建议先完成以下检查。
首先记录正在运行的内核，而不只是已经安装的内核包。以下命令仅用于查看：
1 | uname -r |
然后核对发行版公告和对应内核包的补丁记录。企业发行版常将修复回移到自己的版本，版本号没有达到 7.2.9，不等于缺少补丁；反过来，也不能因为软件源里有新包，就认定节点已经运行新内核。升级后的启动验证仍然必要。
可以向发行版维护方提供这两个上游提交作为核对依据：
dad19b59da05：修复 helper 引用扩展区后发生重分配的问题。f85009dfcd65：避免修改共享且未确认的连接跟踪条目。
其次检查实际使用的流量处理规则。下面是查看指定接口 ingress 过滤器的一种方式，接口名需要替换为节点上的真实设备：
1 | tc -s filter show dev <接口名> ingress |
这只是一个排查入口，并不覆盖 egress、其他链或全部接口。平台可能还有自动生成的规则，应结合网络插件和虚拟交换机的配置核对 ct、NAT、helper、标记及标签的使用情况。不要为了排查而直接删除生产规则，也不要把原始规则和业务地址公开到文章或工单之外。
升级验证要覆盖业务，而不只看节点能启动
确认需要更新后，优先沿用发行版支持的内核包和维护流程。在代表性测试节点上验证，再分批安排生产升级，并保留旧内核启动项和远程恢复入口。
网络验证至少应关注新连接建立、长连接维持、NAT 转换、连接标记及标签是否符合预期。如果实际启用了相关 helper，还应覆盖依赖它的业务。硬件卸载、报文镜像或复杂转发链路属于需要额外核对的环境差异，不能用一台简单测试机的结果替代全部节点。
这些是针对补丁机制提出的工程建议，不是本文已经完成的业务实测。对线上系统，应结合内核日志、丢包统计、连接失败率和现有监控判断升级效果。
结语
Linux 7.2.9 的这组修复值得网络平台团队关注，因为它处理的是连接跟踪状态、扩展数据和共享引用之间的具体关系。升级决策应落到三个可核对的事实：运行中的内核是什么、发行版是否已包含修复、业务规则是否使用相关路径。
把这三项查清，再安排针对性的回归测试，稳定版更新才会成为可验证的维护工作。
参考来源
- Linux 官方发布元数据：releases.json，核对 7.2.9 的发布日期。该页面随新版本发布更新。
- Linux 7.2.9 官方变更记录，包含本次稳定分支回移的两项修复。
- 上游提交：act_ct 修复 helper 因扩展区重分配引起的 UAF，用于核对调用顺序与接口行为。
- 上游提交：避免修改共享且未确认的连接跟踪条目，用于核对克隆报文、NAT 与条目重置的处理。