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

  - eth： fbnic：使用 Rx 佇列 napi 指標尋找 napi 向量 佇列管理 ndos 會為 Rx 佇列挑選 napi 向量，其中包含： nv = fbn->napi[idx % fbn->num_napi];問題是，這僅在沒有獨立 Tx 向量的情況下才正確。在這些情況下，我們先分配 Tx 向量，然後再分配 Rx，因此佇列將指向 Tx NAPI 向量，而不是 Rx 向量。ndo 想要的映射已經記錄下來。fbnic_set_netif_napi（） 使用 netif_queue_set_napi（） 發布它，將 napi 指標儲存在 netdev_rx_queue.napi 中，fbnic_reset_netif_napi（） 再次清除它。兩者都在佇列管理 ndos 也持有的 netdev 實例鎖定下執行，因此可以直接讀取指標。使用它並消除分歧。當資料路徑關閉時，指標正好為 NULL，因此 fbnic_queue_mem_alloc（） 可以拒絕該情況，而不是進入釋放狀態：
    netdev_rx_queue_restart（） 在測試 netif_running（） 之前呼叫它，而 fbnic_pm_suspend（） 在從未完成的 PCIe 復原中保留 netif_running（） true，因此佇列重新啟動可以在 fbnic_stop（） 釋放環和向量之後到達。fbnic_stop（） 在 fbnic_free_napi_vectors（） 之前清除 fbnic_reset_netif_queues（） 中的關聯，因此一律先發布 NULL。
    fbnic_queue_start（） 和 fbnic_queue_stop（） 不需要自行檢查，因為只有在 fbnic_queue_mem_alloc（） 在同一執行個體鎖定下成功時，netdev_rx_queue_reconfig（） 才會到達它們。（CVE-2026-98617）

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

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

  - eth：fbnic：使用 Rx 队列 napi 指针查找 napi 矢量 队列管理 ndo 通过以下命令为 Rx 队列选择 napi 矢量：nv = fbn->napi[idx % fbn->num_napi];问题是，这仅在没有独立 Tx 矢量的情况下才正确。在这些情况下，我们首先分配 Tx 矢量，然后分配 Rx，这样队列将指向 Tx NAPI 矢量而不是 Rx 矢量。ndo 想要的映射已记录。fbnic_set_netif_napi（） 通过 netif_queue_set_napi（） 发布它，后者将 napi 指针存储在 netdev_rx_queue.napi 中，fbnic_reset_netif_napi（） 再次将其清除。两者都在队列管理 ndos 还持有的 netdev 实例锁定下运行，因此可直接读取指针。使用它并放弃分歧。当 datapath 向下时，指针正好为 NULL，因此 fbnic_queue_mem_alloc（） 可以拒绝该情况，而不是进入释放状态：
    netdev_rx_queue_restart（） 会在测试 netif_running（） 之前对其进行调用，而 fbnic_pm_suspend（） 会在从未完成的 PCIe 恢复中保留 netif_running（） true，因此队列重新启动可在 fbnic_stop（） 释放环和向量之后到来。fbnic_stop（） 在 fbnic_free_napi_vectors（） 之前清除 fbnic_reset_netif_queues（） 中的关联，因此始终首先发布 NULL。
    fbnic_queue_start（） 和 fbnic_queue_stop（） 不需要自行检查，因为只有当 fbnic_queue_mem_alloc（） 在同一实例锁定下成功时，netdev_rx_queue_reconfig（） 才会到达它们。（CVE-2026-98617）

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

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - eth:fbnic:Rx キュー napi ポインターを使用して napi ベクトルを検索します。キュー管理 ndo は、次で Rx キューの napi ベクトルを選択します:nv = fbn->napi[idx % fbn->num_napi];問題は、これがスタンドアロンの Tx ベクトルがない場合のみ正しいことです。それらの場合、最初に Tx ベクトルを割り当て、次に Rx を割り当てて、キューが Rx ベクトルではなく Tx NAPI ベクトルを指し示すようにしていました。ndos が求めるマッピングは、すでに記録されています。fbnic_set_netif_napi() は、napi ポインターを netdev_rx_queue.napi に保存する netif_queue_set_napi() でそれを公開し、fbnic_reset_netif_napi() はそれを再度クリアします。どちらも、キュー管理 ndos も保持する netdev インスタンスロックの下で実行されるため、ポインターを直接読み取ることができます。それを使用して、分割をドロップします。データパスがダウンしている間はポインターが NULL であるため、fbnic_queue_mem_alloc() は解放された状態になるのではなく、そのケースを拒否できます。
    netdev_rx_queue_restart()はnetif_running()をテストする前にそれを呼び出し、fbnic_pm_suspend()は完了しないPCIeリカバリ全体でnetif_running()をtrueのままにします。したがって、キューの再起動は、fbnic_stop()がリングとベクトルを解放した後に到着する可能性があります。fbnic_stop() は fbnic_free_napi_vectors() の前の fbnic_reset_netif_queues() の関連付けをクリアするため、NULL は常に最初に公開されます。
    fbnic_queue_start() と fbnic_queue_stop() は、同じインスタンスロックの下で fbnic_queue_mem_alloc() が成功した後にのみ到達するためnetdev_rx_queue_reconfig、それぞれでチェックする必要はありません。(CVE-2026-98617)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - eth: fbnic: use the Rx queue napi pointer to find the napi vector The queue management ndos pick the napi     vector for an Rx queue with: nv = fbn->napi[idx % fbn->num_napi]; The issue is this is only correct in the     cases where there are no standalone Tx vectors. In those cases we were allocating the Tx vectors first and     then the Rx so the queues would be pointing to Tx NAPI vectors instead of the Rx ones. The mapping the     ndos want is already recorded. fbnic_set_netif_napi() publishes it with netif_queue_set_napi(), which     stores the napi pointer in netdev_rx_queue.napi, and fbnic_reset_netif_napi() clears it again. Both run     under the netdev instance lock that the queue management ndos also hold, so the pointer can be read     directly. Use it and drop the divide. The pointer is NULL exactly while the datapath is down, so     fbnic_queue_mem_alloc() can reject that case rather than reaching into freed state:
    netdev_rx_queue_restart() calls it before it tests netif_running(), and fbnic_pm_suspend() leaves     netif_running() true across a PCIe recovery that never completes, so a queue restart can arrive after     fbnic_stop() has freed the rings and the vectors. fbnic_stop() clears the association in     fbnic_reset_netif_queues() before fbnic_free_napi_vectors(), so the NULL is always published first.
    fbnic_queue_start() and fbnic_queue_stop() need no check of their own, as netdev_rx_queue_reconfig() only     reaches them once fbnic_queue_mem_alloc() has succeeded under the same instance lock. (CVE-2026-98617)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
367662	Linux Distros 未修補弱點：CVE-2026-98617	Nessus	Misc.	2026/10/20	2026/10/21	medium
367662	Linux Distros 未修补的漏洞：CVE-2026-98617	Nessus	Misc.	2026/10/20	2026/10/21	medium
367662	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98617	Nessus	Misc.	2026/10/20	2026/10/21	medium
367662	Linux Distros Unpatched Vulnerability : CVE-2026-98617	Nessus	Misc.	2026/10/20	2026/10/21	medium

检测

插件搜索

medium

medium

medium

medium