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

  - xsk：回收 ZC 批次路徑中無效的 Tx 描述元零副本 Tx 批次剖析器在遇到無效的描述元時停止。如果在一或多個接續描述元之後發生這種情況，則 Tx 消費者可以前進，過去既未提交給驅動程式，也未透過完成通道傳回使用者空間的片段。當封包超過xdp_zc_max_segs時，也會出現類似的問題。耗用到限制的描述元會在不完成的情況下釋放，其餘的繼續描述元隨後可以解譯為另一個封包的開頭。以封包單位剖析 Tx 批次，並將屬於完整有效封包的描述元與清空無效或過大的封包時消耗的描述元區分開來。將前者傳回給驅動程式，並將後者附加到 CQ 位址區域，以便使用者空間可以回收其 UMEM 框架。將獨立式無效描述元視為僅限單一描述元回收封包。前進 Tx-ring 消費者會釋放環槽，但本身不會將引用的 UMEM 框架的所有權返回給使用者空間。一旦開始清空，請繼續，直到封包的封包結尾描述元被消耗為止。當尚未提供 EOP 時，保留通訊端上的清空狀態，以便在稍後的呼叫期間繼續清空。將不完整但在其他方面有效的封包保留在 Tx 通道上。使用多緩衝區 Tx 的共用 UMEM 集區也需要封包框架剖析。一次遍歷一個封包的 Tx 通訊端，保留現有的每個通訊端公平性方案，而不是使用舊的單一描述元後援。保留不使用多重緩衝區 Tx 的共用集區的後援。由於每個通訊端都會維護清空狀態，而且單一和共用路徑都可以繼續中斷的清空，因此將通訊端清單從單一變更為共用不需要特殊的繫結時間轉換。CQ 專案是位置的，驅動程式只能完成 xsk_tx_peek_release_desc_batch（） 所傳回的部分 Tx 工作。因此，當早期驅動程式可見描述元仍未完成時，就無法立即發佈僅限回收項目。追蹤回收項目之前的驅動程式可見 CQ 項目數目。讓 xsk_tx_completed（） 發佈部分硬體 Tx 完成，並僅在每個較早的 Tx 描述元完成後發佈回收項目。當前面沒有驅動程式可見的工作時，立即完成僅限回收批次，並防止在回收項目保持擱置狀態時附加另一個 Tx 批次。此外，也會依集區暫存描述元陣列的大小來限制批次處理，因為屬於共用 UMEM 之通訊端的 Tx 通道可能具有不同的大小。這可確保 ZC 批次路徑所耗用的每個無效 Tx 描述元都會作為有效封包的一部分提交給驅動程式，或傳回使用者空間，而不會違反 CQ 完成順序。
    (CVE-2026-74558)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

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

medium Nessus Plugin ID 335767

版本 1.1