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

  - netdsa避免使用可疑的 RCU 用於已同步的 VLAN 感知 MAC 位址若使用 felix 驅動程式 (唯一支援 UC 篩选和 MC 篩選的驅動程式) 做為其他隨機 DSA 交換器的 DSA 主機可查看下列堆疊下游交換器連接埠加入 VLAN 感知橋接器時的追踪
    ============================= 警告可疑的 RCU 使用方式 ---------------- ------------- net/8021q/vlan_core.c:238 可疑的 rcu_dereference_protected() 使用方式堆疊反向追踪工作佇列
    dsa_ordered dsa_slave_switchdev_event_work Call trace: lockdep_rcu_suspicious+0x170/0x210 vlan_for_each+0x8c/0x188 dsa_slave_sync_uc+0x128/0x178 __hw_addr_sync_dev+0x138/0x158 dsa_slave_set_rx_mode+0x58/0x70 __dev_set_rx_mode+0x88/0xa8 dev_uc_add+0x74/0xa0 dsa_port_bridge_host_fdb_add+0xec/0x180 dsa_slave_switchdev_event_work+0x7c/0x1c8 process_one_work+0x290/0x568 這表示從 DSA 主機的 ndo_set_rx_mode() 呼叫 vlan_for_each() 時會預期 rtnl_lock() 內容但並未取得該內容。dsa_slave_set_rx_mode() 的呼叫者是從屬 DSA 介面的 dsa_port_bridge_host_fdb_add()其來自延遲的 dsa_slave_switchdev_event_work()。在認可 0faf890fc519 (netdsadrop rtnl_lock from dsa_slave_switchdev_event_work) 中我們已盡最大努力避免該呼叫路徑中的 rtnl_lock() 內容而且因為呼叫 dsa_flush_workqueue( ) 的呼叫路徑中讀取 (基本上所有)。因此當 DSA 主機從其 ndo_set_rx_mode() 呼叫 vlan_for_each() 時此裝置上的 8021q 驅動程式狀態實際上並未受到任何保護措施的並行存取。查看 net/8021q/我認為 vlan_info->vid_list 在設計時並未特別考慮 RCU 遊走因此引入 RCU 讀取端表單 vlan_for_each() - vlan_for_each_rcu() - 不會那麼容易而且無論如何它也不會完全是我們所需要的。一般而言我認為解決方案不存在於 net/8021q/ 中。 vlan_for_each() 並未就此工作剪除。DSA 不需要保留 rtnl_lock() 本身因為這不是我們要封鎖的 netdev 狀態變更而是只是對 VLAN 清單的並行新增/移除。我們甚至不需要可休眠的內容 - vlan_for_each() 的回呼僅會排程延遲的工作。建議的逸出是為了移除對 vlan_for_each() 的相依性並根據從 .ndo_vlan_rx_add_vid() 和 .ndo_vlan_rx_kill_vid() 修改的 VLAN 清單複本將非休眠、釋放 rtnl 的替代項目開啟程式碼。
    (CVE-2023-54149)

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

偵測

Linux Distros 未修補的弱點：CVE-2023-54149

medium Nessus Plugin ID 280007

版本 1.8