Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net：消耗 GSO 帧的 xmit 错误 udpgro_frglist.sh 和 udpgro_bench.sh 是目前 NIPA 中最不稳定的测试。它们会以完全相同的方式失败，TCP GRO 测试偶尔会停止，且测试会在 10 分钟后终止。这些测试使用 veth 来模拟 GRO。它们附加一个普通（返回XDP_PASS;XDP 程序强制关闭 TSO 并打开 NAPI。深入研究故障模式，我们可以看到连接在爆发性掉线后完全卡住。发送方的snd_nxt序列号为 N [1]，但接收方声称已收到（rcv_nxt）最多 N + 3 * MSS [2]。最后一块拼图是发送方 rtx 队列不是空的（假设 rtx 队列中的块位于序列号 N - 4 * MSS [3]）。在这种状态下，发送方发送来自 rtx 队列的重传具有单一段，序列号为 N-4*MSS：N-3*MSS [3]。接收方看到它并以 ACK 一直响应，最高可达 N + 3 * MSS [2]。
    但是发送者会拒绝此 ack 作为TCP_ACK_UNSENT_DATA，因为它不记得曾经将数据发送到那么远的地方 [1]。我们被困住了。根本原因是 xmit 返回代码的混乱。veth 在无法 xmit 帧时返回错误。我们最终会遇到这样的损失事件：
    ------------------------------------------------- |GSO超级车架1 |GSO超级车架2 | |-----------------------------------------------| |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 | |1 |2 |3 |4 |5 |6 |7 |8 |------------------------------------------------- x ok ok | <ok>ok ok ok \ <x> \ snd_nxt x 表示 veth 丢失的数据包，ok 表示它通过了。由于 veth 在此测试中禁用了 TSO，所以它可以看到各个段。段 1 位于重传队列中，将被重新发送。那么，为什么发送方没有前进snd_nxt即使它显然已经发送到第 8 段呢？tcp_write_xmit（） 会将来自核心的返回代码解释为表示根本未发送数据。由于 TCP 处理的是 GSO 超帧，而不是单个段，因此问题的关键在于单个段的丢失可解释为全部丢失。TCP 只看到 GSO 帧最后一段的最后一个返回代码（在上图中的<>括号中）。当然，要使问题发生，我们需要一个没有 Qdisc 的设置或设备。
    否则，Qdisc 层会完全断开协议层与设备错误的连接。我们有多种方法可以解决此问题。1） 使 veth 在丢失数据包时不返回错误。虽然我认为这是我们过去所做的，但问题不断重复出现，调试起来很烦人。打痣的游戏并不好。2） 修复该死的返回代码我们在文档中只讨论NETDEV_TX_OK和NETDEV_TX_BUSY，所以也许我们应该将 ndo_start_xmit（） 的返回代码设为布尔值。我最喜欢它，但也许一些古老的、不是真正的网络协议会受到影响。3） 使 TCP 忽略错误我并不完全清楚 TCP 从解释 ip_queue_xmit（） 的结果中获得了什么好处？具体来说，一旦建立了连接并且我们正在推送数据 - 数据包丢失只是数据包丢失吗？4） 此补丁 忽略 Qdisc-less+GSO 情况中的 rc，因为它不可靠。在TCQ_F_CAN_BYPASS的情况下，我们已始终返回 OK。在无 Qdisc 的情况下，我们保守一点，仅掩盖 GSO 错误。此路径由非 IP 网络（如 CAN、MCTP 等）采用，因此我们可以回归一些古老的事物。这是最简单的，但也可能是最黑客的修复？Eric 过去曾提出过类似的修复方案，但从未提交，因为原始报告者使用 OOT 驱动程序且未提供反馈（参见链接）。（CVE-2026-43194）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-43194

high Nessus 插件 ID 312744

版本 1.9