Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - gve：使用 header-split 和 HW-GRO 修正標頭緩衝區損毀 DQO RX 資料路徑會在發佈時對 per-buffer-queue-descriptor header_buf_addr程式設計，並在完成時讀回分割標頭。post 和讀取目前都會依佇列位置而不是緩衝區的身分識別來索引標頭緩衝區： - post （gve_rx_post_buffers_dqo）：header_buf_addr是從 bufq->tail 計算的 - 讀取 （gve_rx_dqo）：從desc_idx讀取標頭 （完成佇列頭索引） 這取決於緩衝區佇列索引和每個封包開頭的完成佇列索引相等， 也就是說，在取用張貼緩衝區的裝置上，並以完全相同的順序傳回完成。一旦啟用多個流程的 HW-GRO ，此假設就不成立：接受並完成合併的區段的順序可能與張貼緩衝區的順序不同，而且來自不同流量的區段可能會交錯。這會導致兩個問題： 1. 讀取時標頭插槽錯誤。因為讀取位移衍生自完成索引 （desc_idx） ，而裝置會將標頭寫入針對緩衝區buf_id程式設計的位址，所以驅動程式可以複製屬於不同封包的標頭。這顯示為吞吐量下降（大約 30% 下降和大量 TCP 重新傳輸），同時啟用了標頭分割和 HW-GRO 並且有許多流。2. 標頭緩衝區在仍由裝置擁有時重複使用。驅動程式每次完成時將 bufq->head 前進 1 次，並據此重新張貼緩衝區。N 個 RX 完成的到達僅保證裝置至少已讀取 N 個 RX 緩衝區描述元。它不保證裝置已放棄對應至這 N 個描述元的所有緩衝區擁有權。例如，複製到緩衝區 N 的封包完成會在複製到緩衝區 N-1 的封包完成之前到達，驅動程式可以重新張貼並覆寫裝置仍要寫入的標頭緩衝區，損毀尚未處理完成的封包標頭。
    藉由在張貼和讀取路徑上buf_id，為標頭緩衝區編製索引，以解決這兩個問題。因此，無論完成順序如何，從buf_id的插槽讀取始終是正確的（修正了問題 1）。依 buf_id 編製索引也會將每個標頭插槽繫結至其緩衝區狀態的存留期。緩衝區狀態只有在處理其自己的完成 （buf_id） 時才會傳回至釋放/回收清單，因此只有在裝置完成之後，才能重新張貼其標頭位置。這使得標頭插槽在無序完成下是安全的（修正了問題 2）。根據num_buf_states配置 （gve_rx_alloc_hdr_bufs） 和釋放 （gve_rx_free_hdr_bufs） 標頭緩衝區，以符合buf_id索引。（CVE-2026-72046）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-72046

critical Nessus Plugin ID 337371

版本 1.6