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

  - gve：修复 header-split 和 HW-GRO 的标头缓冲区损坏 DQO RX 数据路径在发布时对 per-buffer-queue-descriptor header_buf_addr进行编程，并在完成时读回拆分标头。post 和 read 当前都按队列位置而不是缓冲区的身份为标头缓冲区编制索引：- post （gve_rx_post_buffers_dqo）：从 bufq->tail 计算header_buf_addr - read （gve_rx_dqo）：从 desc_idx 读取标头（完成队列头索引） 这依赖于缓冲区队列索引和完成队列索引对于每个数据包的开头相等， 即在消耗已发布缓冲区并以完全相同的顺序返回完成的设备上。一旦通过多个流启用了 HW-GRO，该假设就不成立：合并的段被接受和完成，其顺序可能与发布缓冲区的顺序不同，并且来自不同流的段可能会交错。这会导致两个问题：1. 读取时错误的标头槽。由于设备将标头写入针对缓冲区buf_id编程的地址时，读取偏移量源自完成索引 （desc_idx），因此驱动程序可以复制属于其他数据包的标头。在同时启用了标头拆分和许多流的情况下，这显示为吞吐量下降（大约 30% 的下降和大量 TCP 重新传输）。2. 仍归设备所有时重用标头缓冲区。驱动程序会每完成一次 bufq->head 前进一次，并据此重新发布缓冲区。N RX 完成的到达仅保证设备至少读取了 N 个 RX 缓冲区描述符。它不保证设备已放弃与这 N 个描述符对应的所有缓冲区的所有权。对于无序完成（例如，复制到缓冲区 N 的数据包的完成先于复制到缓冲区 N-1 的数据包完成），驱动程序可重新发布并覆盖设备仍要写入的标头缓冲区，从而损坏尚未处理完成的数据包的标头。
    通过在发布和读取路径上buf_id为标头缓冲区编制索引，修复了这两个问题。因此，无论完成顺序如何，从 buf_id 插槽读取始终正确（修正问题 1）。buf_id索引还将每个标头槽与其缓冲区状态的生命周期联系起来。缓冲区状态只有在处理其自身的完成 （buf_id） 时才会返回到释放/回收列表，所以只有在设备完成其使用后，才能重新发布其标头槽。这可使无序完成下的标头槽重用安全（修复问题 2）。根据匹配buf_id索引的num_buf_states分配 （gve_rx_alloc_hdr_bufs） 和释放 （gve_rx_free_hdr_bufs） 标头缓冲区。（CVE-2026-72046）

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

检测

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

critical Nessus 插件 ID 337371

版本 1.3