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

  - mlxsw： spectrum_ptp：修正來自 GC 工作佇列內容的 napi_gro_receive（） 呼叫 目前 mlxsw_sp1_ptp_ht_gc_collect（） 是從 PTP 記憶體回收工作佇列執行，而不是從 NAPI 輪詢內容執行。對於攜帶 SKB 的任何不相符的 PTP 項目，它會呼叫 mlxsw_sp1_ptp_unmatched_finish（） -> mlxsw_sp1_ptp_packet_finish（）。對於輸入封包，這會呼叫 mlxsw_sp_rx_listener_no_mark_func（）。該函數的結尾如下：skb->protocol = eth_type_trans（skb， skb->dev）;
    napi_gro_receive（mlxsw_skb_cb（skb）->rx_md_info.napi， skb）;napi 指標是在 NAPI 內容中收到被困封包時放置在 SKB 控制區塊中的指標。稍後，當 GC 收穫不相符的項目 （最多 MLXSW_SP1_PTP_HT_GC_TIMEOUT 之後） 時，對 napi_gro_receive（） 的呼叫會改變 NAPI 實例的 GRO 清單，如果輪詢在另一個 CPU 上同時執行，則這是不安全的。在 mlxsw_sp1_ptp_ht_gc_collect（） 中，呼叫 local_bh_disable（） 來阻止 softirq 處理，但這僅適用於本機 CPU。此外，它的評論是陳舊的。它指出 mlxsw_sp1_ptp_unmatched_finish（） 叫用 netif_receive_skb（）。自引用提交以來，這一直不準確;此修補程式使該評論再次準確。mlxsw_pci_napi_devs_init（） 在 NAPI RX net_device上呼叫 netif_threaded_enable（），沒有任何條件。NAPI 執行個體的輪詢可能與 GC 同時執行，但會以獨立排程的 kthread 身分執行，該 kthread 可能位於不同的 CPU 上。對 local_bh_disable（） 的呼叫並不能防止這種情況發生。如果 tx-timestamp 逾時產生不相符的項目 （可以透過執行 ptp4l 並等待連接埠達到 UNCALIBRATED/SLAVE 狀態輕鬆重現），而擁有的 NAPI 執行緒正在另一個 CPU 上進行輪詢，則雙方會同時更改 GRO 清單，如下所示： [39.846] 連接埠 1 （swp1）： MASTER 至 UNCALIBRATED on RS_SLAVE list_add corruption. next->prev 應該是 prev （ffff8d620faf4138）， 而是 ffff8d624150f700。（next=ffff8d620faf4138）. lib/list_debug.c：29 的核心錯誤！哎呀：無效的操作碼：0000 [#1] SMP PTI CPU：1 UID：0 PID：539 通訊：napi/mlxsw_rx-0 未受 6.18.48 #1污染 -NixOS PREEMPT（lazy） 硬體名稱：Mellanox Technologies Ltd. MSN2410/VMOD0001， BIOS 4.6.5 09/13/2018 RIP：
    0010：__list_add_valid_or_report+0x79/0xb0 RSP：0018：ffffcdf8c0f27c08 EFLAGS：00010246 RAX：
    0000000000000075 RBX：ffff8d624150fd00 RCX：0000000000000000000 RDX：000 0000000000000001 R08R09R100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    ffffffffa5c60fe0 R11： ffffcdf8c0f27ab8 R12： 0000000000000003 R13： 000000000000003d R14： 00000000000001bc R15： 0000000000000001 FS： 000000000000000000（0000） GS：GS： ffff8d636f63f000（0000） knlGS：00000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：0000562689a60c24 CR3：000000015f224004 CR4：00000000001726f0 呼叫追蹤： <TASK> gro_receive_skb+0xee/0x230 mlxsw_sp1_ptp_got_packet+0x61/0x140 [mlxsw_spectrum] mlxsw_core_skb_receive+0xdf/0x1b0 [mlxsw_core]mlxsw_pci_napi_poll_cq_rx+0x780/0x9d0 [mlxsw_pci]
    __napi_poll+0x31/0x1e0 napi_threaded_poll_loop+0x16b/0x1c0 napi_threaded_poll+0x71/0xa0 kthread+0xfb/0x260 ret_from_fork+0x22d/0x260 ret_from_fork_asm+0x1a/0x30 </TASK> 核心錯誤 - 未同步： 中斷中的嚴重異常 導致此核心錯誤的機制尚未在 和主線之間 6.18.48 變更。此修補程式為呼叫 netif_receive_skb（） 而不是 napi_gro_receive（） 的 PTP packet_finish（） 路徑新增了輸入傳遞協助程式。netif_receive_skb（） 與 napi_gro_receive（） 不同，可以從 NAPI 實例的輪詢內容外部呼叫，這可能發生在此路徑的呼叫站點。
    RX 統計記帳和 skb->dev 指派仍會保留;唯一的變化是傳遞呼叫本身。這會移除 GR ---truncated--- （CVE-2026-98050）

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

偵測

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

high Nessus Plugin ID 350416

版本 1.9