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

  - net/smc遞補後將喚醒轉送至 smc 通訊端 waitqueue我們將 TCP 取代為 SMC 且發生遞補時smc socket->wq 中可能會保留一些通訊端 waitqueue 項目例如使用者空間應用程式插入的 eppoll_entries。遞補之後資料會透過 TCP/IP 傳輸且只會喚醒 clcsocket->wq。遞補之前插入 smc socket->wq 的項目無法通知應用程式。因此我們需要一個機制來同時喚醒 smc socket->wq (若其中有項目剩餘)。目前的因應措施是在遞補期間將項目從 smc socket->wq 傳輸至 clcsock->wq。但這可能會造成類似下面的損毀一般保護錯誤可能針對非正式位址 0xdead0000000001000000 [#1] PREEMPT SMP PTI CPU3 PID0 Commswapper/3 Kdump已載入 污染
    GE 5.16.0+ #107 RIP 0010:__wake_up_common+0x65/0x170 呼叫追踪 <IRQ> __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 當 版sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? tcp_v4_early_demux+0xa2/0x140 tcp_v4_early_demux+0x10d/0x140 ip_sublist_rcv_finish+0x49/0x60 ip_sublist_rcv+0x19d/0x230 ip_list_rcv+0x13e/0x170 __netif_receive_skb_list_core+0x1c2/0x240 netif_receive_skb_list_internal+0x1e6/0x320 napi_complete_done+0x11d/0x190 mlx5e_napi_poll+0x163/0x6b0 [mlx5_core] __napi_poll+0x3c/0x1b0 net_rx_action+ 0x27c/0x300 __do_softirq+0x114/0x2d2 irq_exit_rcu+0xb4/0xe0 common_interrupt+0xba/0xe0 </IRQ> <TASK> 將 waitqueue 項目從 smc socket->wq 私下傳輸至 clcsock->wq 時會造成當機。這些項目的擁有者 (例如 epoll) 並不知道項目已傳輸至不同的通訊端等待佇列而且仍然使用原始的等待佇列執行緒同步鎖定 (smc socket->wq.wait.lock) 使項目作業獨占但是無法運作。對項目執行的作業 (例如從 waitqueue 中移除) (遞補後為 clcsock->wq)可能在反覆使用 clcsock waitqueue 時造成當機。此修補程式嘗試透過不再私下傳輸等待佇列項目而是在遞補情況中引入自己的 clcsock 回呼函式實作來修正此問題。若 clcsock->wq 實際已喚醒且 smc socket->wq 有剩餘項目則回呼函式會將喚醒轉送至 smc socket->wq。 (CVE-2022-48721)

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

偵測

Linux Distros 未修補的弱點：CVE-2022-48721

medium Nessus Plugin ID 225626

版本 1.10