{"id":29205,"date":"2026-09-25T20:32:08","date_gmt":"2026-09-25T12:32:08","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98050"},"modified":"2026-09-25T20:32:08","modified_gmt":"2026-09-25T12:32:08","slug":"cve-2026-98050","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98050","title":{"rendered":"CVE-2026-98050 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_ptp:"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context<\/p>\n<p>Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the PTP<br \/>\ngarbage-collection workqueue, rather than the NAPI poll context. For any<br \/>\nunmatched PTP entries carrying an SKB, it calls<br \/>\nmlxsw_sp1_ptp_unmatched_finish() -&gt; mlxsw_sp1_ptp_packet_finish(). For<br \/>\ningress packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The end<br \/>\nof that function is the following:<\/p>\n<p>    skb-&gt;protocol = eth_type_trans(skb, skb-&gt;dev);<br \/>\n    napi_gro_receive(mlxsw_skb_cb(skb)-&gt;rx_md_info.napi, skb);<\/p>\n<p>The napi pointer is one that was placed in the SKB control block when the<br \/>\ntrapped packet was received in the NAPI context. Later, when the GC reaps<br \/>\nthe unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later), the call to<br \/>\nnapi_gro_receive() mutates the NAPI instance&#8217;s GRO list, which is unsafe<br \/>\nif the poll is running concurrently on another CPU.<\/p>\n<p>In mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to prevent<br \/>\nsoftirq processing, but this only applies to the local CPU. Additionally,<br \/>\nits comment is stale. It states that mlxsw_sp1_ptp_unmatched_finish()<br \/>\ninvokes netif_receive_skb(). This has not been accurate since the<br \/>\nreferenced commit; this patch makes that comment accurate again.<br \/>\nmlxsw_pci_napi_devs_init() calls netif_threaded_enable() on the NAPI RX<br \/>\nnet_device without any conditions. The NAPI instance&#8217;s poll, which may be<br \/>\nrunning concurrent to the GC, is running as an independently-scheduled<br \/>\nkthread which may be on a different CPU. The call to local_bh_disable()<br \/>\ndoes not guard against this.<\/p>\n<p>If a tx-timestamp timeout produces an unmatched entry (which can be easily<br \/>\nreproduced by running ptp4l and waiting for a port to reach the<br \/>\nUNCALIBRATED\/SLAVE state) while the owning NAPI thread is in the middle of<br \/>\na poll on another CPU, both sides mutate the GRO list concurrently, as<br \/>\nshown below:<\/p>\n<p>  [39.846] port 1 (swp1): MASTER to UNCALIBRATED on RS_SLAVE<br \/>\n  list_add corruption. next-&gt;prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138).<br \/>\n  kernel BUG at lib\/list_debug.c:29!<br \/>\n  Oops: invalid opcode: 0000 [#1] SMP PTI<br \/>\n  CPU: 1 UID: 0 PID: 539 Comm: napi\/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy)<br \/>\n  Hardware name: Mellanox Technologies Ltd. MSN2410\/VMOD0001, BIOS 4.6.5 09\/13\/2018<br \/>\n  RIP: 0010:__list_add_valid_or_report+0x79\/0xb0<br \/>\n  RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246<br \/>\n  RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000<br \/>\n  RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540<br \/>\n  RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff<br \/>\n  R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003<br \/>\n  R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001<br \/>\n  FS:  0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000<br \/>\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br \/>\n  CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0<br \/>\n  Call Trace:<\/p>\n<p>  gro_receive_skb+0xee\/0x230<br \/>\n  mlxsw_sp1_ptp_got_packet+0x61\/0x140 [mlxsw_spectrum]<br \/>\n  mlxsw_core_skb_receive+0xdf\/0x1b0 [mlxsw_core]<br \/>\n  mlxsw_pci_napi_poll_cq_rx+0x780\/0x9d0 [mlxsw_pci]<br \/>\n  __napi_poll+0x31\/0x1e0<br \/>\n  napi_threaded_poll_loop+0x16b\/0x1c0<br \/>\n  napi_threaded_poll+0x71\/0xa0<br \/>\n  kthread+0xfb\/0x260<br \/>\n  ret_from_fork+0x22d\/0x260<br \/>\n  ret_from_fork_asm+0x1a\/0x30<\/p>\n<p>  Kernel panic &#8211; not syncing: Fatal exception in interrupt<\/p>\n<p>The machinery that leads to this kernel panic has not been changed between<br \/>\n6.18.48 and mainline.<\/p>\n<p>This patch adds an ingress-delivery helper for the PTP packet_finish()<br \/>\npath that calls netif_receive_skb() instead of napi_gro_receive().<br \/>\nnetif_receive_skb(), unlike napi_gro_receive(), can be called from outside<br \/>\nof the NAPI instance&#8217;s poll context, which can occur at the call site for<br \/>\nthis path. RX stats accounting and the skb-&gt;dev assignment are still<br \/>\npreserved; the only change is the delivery call itself.<\/p>\n<p>This removes GR<br \/>\n&#8212;truncated&#8212;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context<\/p>\n<p>Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-29205","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/29205","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29205"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29205"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29205"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}