There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ptp: Fix
    napi_gro_receive() call from GC workqueue context Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the
    PTP garbage-collection workqueue, rather than the NAPI poll context. For any unmatched PTP entries
    carrying an SKB, it calls mlxsw_sp1_ptp_unmatched_finish() -> mlxsw_sp1_ptp_packet_finish(). For ingress
    packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The end of that function is the following:
    skb->protocol = eth_type_trans(skb, skb->dev); napi_gro_receive(mlxsw_skb_cb(skb)->rx_md_info.napi, skb);
    The napi pointer is one that was placed in the SKB control block when the trapped packet was received in
    the NAPI context. Later, when the GC reaps the unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later),
    the call to napi_gro_receive() mutates the NAPI instance's GRO list, which is unsafe if the poll is
    running concurrently on another CPU. In mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to
    prevent softirq processing, but this only applies to the local CPU. Additionally, its comment is stale. It
    states that mlxsw_sp1_ptp_unmatched_finish() invokes netif_receive_skb(). This has not been accurate since
    the referenced commit; this patch makes that comment accurate again. mlxsw_pci_napi_devs_init() calls
    netif_threaded_enable() on the NAPI RX net_device without any conditions. The NAPI instance's poll, which
    may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a
    different CPU. The call to local_bh_disable() does not guard against this. If a tx-timestamp timeout
    produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to
    reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another
    CPU, both sides mutate the GRO list concurrently, as shown below: [39.846] port 1 (swp1): MASTER to
    UNCALIBRATED on RS_SLAVE list_add corruption. next->prev should be prev (ffff8d620faf4138), but was
    ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000
    [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy)
    Hardware name: 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: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001
    RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10:
    ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc
    R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010
    DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0
    Call Trace: <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> Kernel panic - not syncing: Fatal exception
    in interrupt The machinery that leads to this kernel panic has not been changed between 6.18.48 and
    mainline. This patch adds an ingress-delivery helper for the PTP packet_finish() path that calls
    netif_receive_skb() instead of napi_gro_receive(). netif_receive_skb(), unlike napi_gro_receive(), can be
    called from outside of the NAPI instance's poll context, which can occur at the call site for this path.
    RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call
    itself. This removes GR ---truncated--- (CVE-2026-98050)

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/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（） 的调用无法防止此情况发生。如果拥有的 NAPI 线程处于另一个 CPU 上的轮询中时，tx-timestamp 超时产生不匹配的条目（可通过运行 ptp4l 并等待端口达到 UNCALIBRATED/SLAVE 状态轻松重现），则两端会同时改变 GRO 列表，如下所示： [39.846] 端口 1 （swp1）： RS_SLAVE list_add 损坏时 MASTER 到 UNCALIBRATED 的 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 2018 年 9 月 13 日 RIP：
    0010：__list_add_valid_or_report+0x79/0xb0 RSP：0018：ffffcdf8c0f27c08 EFLAGS：00010246 RAX：
    0000000000000075 RBX：ffff8d624150fd00 RCX：00000000000000000 RDX：000000000000000000 RSI：0000000000000001 RDI：ffff8d6315d1e540 RBP：ffff8d620faf4070 R08：000000000000000 R09：00000000ffffdfff R10：
    fffffffffa5c60fe0 R11： ffffcdf8c0f27ab8 R12： 0000000000000003 R13： 000000000000003d R14： 00000000000001bc R15： 0000000000000001 FS： 000000000000000（0000） GS：ffff8d636f63f000（0000） knlGS：0000000000000000 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（） 路径添加了一个入口传送帮助程序。与 napi_gro_receive（） 不同，netif_receive_skb（） 可以从 NAPI 实例的轮询上下文外部调用，这可以在此路径的调用站点上发生。
    RX 统计数据统计和 skb->dev 分配仍保留;唯一的更改是传递调用本身。这会移除 GR ---truncated--- （CVE-2026-98050）

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

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

  - mlxsw:spectrum_ptp:GC ワークキューコンテキストからの napi_gro_receive() 呼び出しを修正します。現在、mlxsw_sp1_ptp_ht_gc_collect() は NAPI ポーリングコンテキストではなく、PTP ガベージコレクションワークキューから実行されています。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() では、softirq 処理を防止するために local_bh_disable() が呼び出されますが、これはローカル CPU にのみ適用されます。さらに、そのコメントは古くなっています。これは、mlxsw_sp1_ptp_unmatched_finish() が netif_receive_skb() を呼び出すことを述べています。これは、参照されたコミット以来正確ではありませんでした。このパッチにより、そのコメントが再び正確になります。mlxsw_pci_napi_devs_init() は、NAPI RX net_device上で netif_threaded_enable() を条件なしで呼び出します。NAPI インスタンスのポールは、GC と並行して実行されている可能性がありますが、異なる CPU 上にある可能性がある、独立してスケジュールされた kthread として実行されています。local_bh_disable() への呼び出しは、これに対して保護しません。所有している NAPI スレッドが別の CPU でのポーリングの途中にあるときに tx-timestamp タイムアウトが一致しないエントリを生成する場合(これは、ptp4l を実行し、ポートが UNCALIBRATED/SLAVE 状態になるのを待機することで簡単に再現できます)、以下に示すように、両側が GRO リストを同時に変更します: [39.846] ポート 1(swp1): RS_SLAVE list_add破損時に MASTER を UNCALIBRATED にします。 next->prev は prev である必要があります(ffff8d620faf4138)、 しかし、ffff8d624150f700 でした。(next=ffff8d620faf4138)。 lib/list_debug.c:29! でのカーネルバグOops:無効な opcode: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: 000000000000000000 RDX: 000000000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 000000000ffffdffff R10:
    fffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001 FS: 000000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS:0010 DS:0000 ES:0000 CR0:0000000080050033 CR2:0000562689a60c24 CR3:000000015f224004 CR4:000000000001726f0 コールトレース: <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 とメインラインの間で変更されていません。このパッチは、napi_gro_receive()の代わりにnetif_receive_skb()を呼び出すPTP packet_finish()パスのingress-delivery helperを追加します。netif_receive_skb() は、napi_gro_receive() とは異なり、NAPI インスタンスのポーリングコンテキストの外部から呼び出される可能性があり、これはこのパスの呼び出しサイトで発生する可能性があります。
    RX stats アカウンティングおよび skb->dev 割り当ては、依然として保持されています。唯一の変更は、配信呼び出し自体です。これは GR ---truncated--- を削除します(CVE-2026-98050)

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

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

  - mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context Currently     mlxsw_sp1_ptp_ht_gc_collect() is run from the PTP garbage-collection workqueue, rather than the NAPI poll     context. For any unmatched PTP entries carrying an SKB, it calls mlxsw_sp1_ptp_unmatched_finish() ->     mlxsw_sp1_ptp_packet_finish(). For ingress packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The     end of that function is the following: skb->protocol = eth_type_trans(skb, skb->dev);
    napi_gro_receive(mlxsw_skb_cb(skb)->rx_md_info.napi, skb); The napi pointer is one that was placed in the     SKB control block when the trapped packet was received in the NAPI context. Later, when the GC reaps the     unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later), the call to napi_gro_receive() mutates the NAPI     instance's GRO list, which is unsafe if the poll is running concurrently on another CPU. In     mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to prevent softirq processing, but this only     applies to the local CPU. Additionally, its comment is stale. It states that     mlxsw_sp1_ptp_unmatched_finish() invokes netif_receive_skb(). This has not been accurate since the     referenced commit; this patch makes that comment accurate again. mlxsw_pci_napi_devs_init() calls     netif_threaded_enable() on the NAPI RX net_device without any conditions. The NAPI instance's poll, which     may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a     different CPU. The call to local_bh_disable() does not guard against this. If a tx-timestamp timeout     produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to     reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another     CPU, both sides mutate the GRO list concurrently, as shown below: [39.846] port 1 (swp1): MASTER to     UNCALIBRATED on RS_SLAVE list_add corruption. next->prev should be prev (ffff8d620faf4138), but was     ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000     [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy)     Hardware name: 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: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001     RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10:
    ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc     R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0     Call Trace: <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> Kernel panic - not syncing: Fatal exception     in interrupt The machinery that leads to this kernel panic has not been changed between 6.18.48 and     mainline. This patch adds an ingress-delivery helper for the PTP packet_finish() path that calls     netif_receive_skb() instead of napi_gro_receive(). netif_receive_skb(), unlike napi_gro_receive(), can be     called from outside of the NAPI instance's poll context, which can occur at the call site for this path.
    RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call     itself. This removes GR ---truncated--- (CVE-2026-98050)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
474658	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Cloud Security	Chainguard Local Security Checks	2026/10/16	2026/10/16	high
475219	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	2026/10/16	2026/10/16	high
475219	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	2026/10/16	2026/10/16	high
474658	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	2026/10/16	2026/10/16	high
350416	Linux Distros 未修補弱點：CVE-2026-98050	Nessus	Misc.	2026/9/25	2026/10/5	high
350416	Linux Distros 未修补的漏洞：CVE-2026-98050	Nessus	Misc.	2026/9/25	2026/10/5	high
350416	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98050	Nessus	Misc.	2026/9/25	2026/10/5	high
350416	Linux Distros Unpatched Vulnerability : CVE-2026-98050	Nessus	Misc.	2026/9/25	2026/10/5	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high