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

  - net: openvswitch: fix race on port output assume the following setup on a single machine: 1. An     openvswitch instance with one bridge and default flows 2. two network namespaces server and client 3.
    two ovs interfaces server and client on the bridge 4. for each ovs interface a veth pair with a     matching name and 32 rx and tx queues 5. move the ends of the veth pairs to the respective network     namespaces 6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)     7. start some http server on the server network namespace 8. test if a client in the client namespace can     reach the http server when following the actions below the host has a chance of getting a cpu stuck in a     infinite loop: 1. send a large amount of parallel requests to the http server (around 3000 curls should     work) 2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill     the namespace) there is a low chance that this will cause the below kernel cpu stuck message. If this does     not happen just retry. Below there is also the output of bpftrace for the functions mentioned in the     output. The series of events happening here is: 1. the network namespace is deleted calling     `unregister_netdevice_many_notify` somewhere in the process 2. this sets first `NETREG_UNREGISTERING` on     both ends of the veth and then runs `synchronize_net` 3. it then calls `call_netdevice_notifiers` with     `NETDEV_UNREGISTER` 4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a     vport is found, which is the case for the veth interface attached to ovs) 5. this removes the rx_handlers     of the device but does not prevent packages to be sent to the device 6. `dp_device_event` then queues the     vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration     path 7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets     `real_num_tx_queues` to 0 8. port deletion continues (but details are not relevant for this issue) 9. at     some future point the background task deletes the vport If after 7. but before 9. a packet is send to the     ovs vport (which is not deleted at this point in time) which forwards it to the `dev_queue_xmit` flow even     though the device is unregistering. In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there     is a while loop (if the packet has a rx_queue recorded) that is infinite if `dev->real_num_tx_queues` is     zero. To prevent this from happening we update `do_output` to handle devices without carrier the same as     if the device is not found (which would be the code path after 9. is done). Additionally we now produce a     warning in `skb_tx_hash` if we will hit the infinite loop. bpftrace (first word is function name):
    __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr:
    0xffff9edb6f207000, reg_state: 1 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues:
    1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server:
    real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 synchronize_rcu_expedited: cpu     9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024     synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024,     tid: 21024 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6,     reg_state: 2 ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state:
    2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2     synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server:
    real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated--- (CVE-2023-53188)

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

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - netopenvswitch修复端口输出上的争用假设在单机上进行以下设置 1. 具有一个桥接和默认流的 openvswitch 实例 2. 两个网络命名空间服务器和客户端 3.
    网桥上的两个 ovs 接口服务器和客户端 4. 为每个 ovs 接口准备一个 veth 对，并包含匹配的名称和 32 个 rx 和 tx 队列 5. 将 veth 对的末端移动到相应的网络命名空间 6. 为每个 分配 IP 地址以命名空间结尾的 veth需要为相同的子网 7. 在服务器网络命名空间上启动某个 http 服务器 8. 测试客户端命名空间中的客户端在遵循主机下的操作时是否可以访问 http 服务器有机会的 cpu 卡在无限循环中的步骤1. 发送大量并行请求到 http 服务器大约 3000 curl 应能工作2. 并行删除网络命名空间不删除接口或停止服务器而只是终止命名空间）极低的机率这将导致以下内核 cpu 卡住消息。如果未发生此情况请重试。下面还有输出中提及的函数的 bpftrace 输出。此处发生的一系列事件为1. 会在进程中的某处调用“unregister_netdevice_many_notify”删除网络命名空间 2. 在 veth 的两端首先设置“NETREG_UNREGISTERING”然后运行“synchronize_net” 3. 然后调用“call_netdevice_notifiers” ` 4。此问题然后由调用“ovs_netdev_detach_dev”的“dp_device_event”进行处理如果找到 vport，即附加到 ovs 的 veth 接口的情况5。这会删除设备的 rx_handlers，但不阻止将程序包发送到设备 6. “dp_device_event”然后将 vport 删除排入队列以便在后台工作，因为我们没有在取消注册路径中保留需要的 ovs_lock 7. “unregister_netdevice_many_notify”继续调用设置“netdev_unregister_kobject”的“netdev_unregister_kobject”将 real_num_tx_queues 设置为 0 8. 端口删除会继续但详细信息与此问题无关9. 在未来的某个时候后台任务会删除 7. 之后 9. 之前的 vport If。一个数据包被发送到 ovs vport在这个时间点未被删除即使设备正在取消注册ovs vport也会将其转发到 `dev_queue_xmit` 流。在 `skb_tx_hash`在 `dev_queue_xmit` 路径中调用存在一个 while 循环如果数据包记录了 rx_queue当 `dev->real_num_tx_queues` 为零时该循环是无限的。为防止发生这种情况我们更新了“do_output”以按照与未找到设备相同的方式处理没有运营商的设备这将是 9. 完成之后的代码路径。此外，如果我们现在遇到无限循环，我们现在会在“skb_tx_hash”中生成警告。 bpftrace第一个单词是函数名称
    __dev_queue_xmit serverreal_num_tx_queues1，cpu:2，pid:28024，tid:28024，skb_addr:
    0xffff9edb6f207000reg_state: 1 netdev_core_pick_tx serveraddr: 0xffff9f0a46d4a000 real_num_tx_queues
    1, cpu2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server
    real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 Synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited, cpu 9pid 9 21024、tid21024 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 dp_device_event serverreal_num_tx_queues: 1 cpu 9、pid:21024、tid21024、event 6、reg_state:2 ovs_netdev_detach_dev server:1, pid21024、tid21024、reg_state
    2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server
    real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated--- (CVE-2023-53188)

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

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

  - netopenvswitchポート出力での競合を修正します。1. つのブリッジとデフォルトフロー2. つのネットワーク名前空間サーバーおよびクライアント 3。
    ブリッジ上の 2 つの ovs インターフェイスサーバーとクライアント 4. 各 ovs インターフェイスに対して、一致する名前と 32 個の rx および tx キューを持つ veth ペア 5. veth ペアの末尾をそれぞれのネットワーク名前空間に移動します 6. それぞれに IP アドレスを割り当てますveth が名前空間で終わります同じサブネットである必要があります7. サーバーネットワークの名前空間で一部の http サーバーを起動します 8。ホストの下のアクションに従うときに、クライアントの名前空間内のクライアントが http サーバーに到達できるかどうかをテストしますCPU が無限ループに陥るのを発見しました1. http サーバーに大量のリクエストを並列に送信します約 3000 の curl が動作します2. ネットワークの名前空間を並列に削除しますインターフェイスを削除したり、サーバーを停止したりせず、単に kill します名前空間) を元に戻します。これにより、以下のカーネル cpu スタックメッセージが発生する可能性は低いです。発生しない場合は、再試行します。以下には、 出力で言及された関数に対する bpftrace の出力も含まれます。ここで発生する一連のイベントは、1. ネットワーク名前空間が削除され、プロセスの任意の場所で「unregister_netdevice_many_notify」を呼び出します。2. これにより、veth の両側で最初の「NETREG_UNREGISTERING」が設定され、続いて「synchronize_net」が実行されます。3. 次に、「call_netdevice_notifiers」が呼び出されます。 ` NETDEV_UNREGISTER' 4 で、これは次に、「ovs_netdev_detach_dev」を呼び出す「dp_device_event」によって処理されますvport が見つかった場合。これは、ovs に添付された veth インターフェイスの場合です5。これにより、デバイスの rx_handlers が削除されますが、パッケージがデバイスに送信されるのを回避しません 6. 「dp_device_event」は、登録解除パスで保留しない ovs_lock が必要なため、vport 削除をバックグラウンドで作業するためにキューに入れます。 7. 「unregister_netdevice_many_notify」は、 設定した「netdev_unregister_kobject」を引き続き呼び出します。 「real_num_tx_queues」を 0 に 8. ポートの削除が継続されますが、この問題には関連性はありません9. ある将来のポイントで、バックグラウンドタスクが vport を削除します7. より後で 9 より前の場合。パケットは、ovs vport に送信され (この時点で削除されない)、デバイスが登録を解除していても、「dev_queue_xmit」フローにパケットを転送します。「skb_tx_hash」これは「dev_queue_xmit」で呼び出されますパスには、「dev->real_num_tx_queues」がゼロの場合に無限になる while ループパケットに rx_queue が記録されている場合があります。これを防ぐために、デバイスが見つからない場合と同じようにキャリアなしでデバイスを処理できるように「do_output」を更新します9. が完了した後のコードパスです。さらに現在は、無限ループに陥る場合に「skb_tx_hash」で警告を生成します。 bpftrace最初の単語が関数名です
    __dev_queue_xmit server: real_num_tx_queues: 1、cpu: 2、pid: 28024、tid: 28024、skb_addr
    0xffff9edb6f207000, reg_state1 netdev_core_pick_tx serveraddr0xffff9f0a46d4a000 real_num_tx_queues
    1、cpu: 2、pid: 28024、tid: 28024、skb_addr: 0xffff9edb6f207000、reg_state: 1 dp_device_event server:
    real_num_tx_queues: 1 cpu 9、pid: 21024、tid: 21024、event 2、reg_state: 1 synchronize_rcu_expeditedcpu 9、pid: 21024、tid: 21024 synchronize_rcu_expedited: cpu 9、pid: 21024、tid: pu 21024、tid: pu 21024 pid: pu 21024 21024、tid21024 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 dp_device_event serverreal_num_tx_queues1 cpu 9、pid21024、tid21024、event6、reg_stateserver21024、tid ovs_netdev_detach pid: 21024、tid: 21024、reg_state
    2 netdev_rx_handler_unregister サーバーreal_num_tx_queues1、cpu9、pid21024、tid21024、reg_state2 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 netdev_rx_handler_unregister ret サーバー
    real_num_tx_queues: 1、cpu: 9、pid: 21024、tid: 21024、reg_state: 2 dp_ ---truncated---CVE-2023-53188]

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

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

  - netopenvswitch修正連接埠輸出的爭用假設單一機器上有下列設定1.一個 openvswitch 執行個體具有一個橋接器和預設流程 2.兩個網路命名空間伺服器和用戶端 3。
    橋接器上有兩個 ovs 介面伺服器和用戶端 4. 針對每個 ovs 介面具有相符名稱和 32 個 rx 與 tx 佇列的 veth 配對 5. 將 veth 配對的末端移至各自的網路命名空間 6. 指派 ip 位址給每個veth 在命名空間結束 (必須是相同的子網路) 7. 啟動伺服器網路命名空間上的某個 http 伺服器 8. 測試用戶端命名空間中的用戶端在執行主機有機會執行下面的動作時是否可連線至 http 伺服器的 cpu 陷入無限迴圈 1. 傳送大量平行要求至 http 伺服器 (約 3000 curls 應運作) 2. 平行刪除網路命名空間 (不刪除介面或停止伺服器而是直接終止命名空間) 的情況下發生下列核心 cpu 停滯訊息的機率很低。如果沒有發生請重試。以下也是輸出中所述函式的 bpftrace 輸出。此處發生的一連串事件如下1. 網路命名空間遭到刪除呼叫處理程序中某處的 `unregister_netdevice_many_notify` 2. 這會先在 veth 的兩端設定 `NETREG_UNREGISTERING`然後執行 `synchronize_net` 3. 然後它會呼叫 `call_netdevice_notifiers ` with `NETDEV_UNREGISTER` 4. 然後這會由呼叫 `ovs_netdev_detach_dev` 的 `dp_device_event` 處理 (如果發現 vport則屬於 ovs 的 veth 介面會屬於這種情況) 5. 這會移除裝置的 rx_handlers 但不會無法防止將套件傳送至裝置 6. 接著「dp_device_event」將 vport 刪除排入佇列以便在背景中運作因為需要我們不在取消註冊路徑中保留的 ovs_lock 7. 「unregister_netdevice_many_notify」繼續呼叫「netdev_unregister_kobject」這會設定`real_num_tx_queues` 至 0 8. 連接埠刪除繼續 (但詳細資訊與此問題無關) 9. 在未來的某個時間點背景工作會刪除 vport If 在 7. 之後但之前在 9.系統會將封包傳送至 ovs vport (此時尚未刪除)即使裝置正在取消註冊仍會將封包轉送至「dev_queue_xmit」流程。在 `skb_tx_hash` (其在 `dev_queue_xmit` 中呼叫) 路徑中有一個 while 迴圈 (如果封包有記錄的 rx_queue) 會在 `dev->real_num_tx_queues` 為零時呈無限狀態。為防止這種情況發生我們更新了「do_output」現可按照找不到裝置的方式處理無載波的裝置 (即 9. 完成後的程式碼路徑)。此外若發生無限迴圈現在會在 `skb_tx_hash` 中產生警告。 bpftrace (第一個字是函式名稱)
    __dev_queue_xmit 伺服器real_num_tx_queues1、cpu 2、pid 28024、tid 28024、skb_addr
    0xffff9edb6f207000、reg_state1 netdev_core_pick_tx 伺服器地址0xffff9f0a46d4a000 real_num_tx_queues
    1、cpu2、pid28024、tid28024、skb_addr0xffff9edb6f207000、reg_state1 dp_device_event 伺服器
    real_num_tx_queues1 cpu 9、pid21024、tid 21024、事件 2、reg_state1 synchronize_rcu_expeditedcpu 9、pid 21024、tid 21024 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 同步、synchronize_rcu_expedited 21024、tid21024 synchronize_rcu_expeditedcpu 9、pid 21024、tid 21024 dp_device_event 伺服器 real_num_tx_queues1 cpu 9、pid 21024、tid 21024、event 6、reg_state2 ovs_netdev_detach_devcpu num_9、twist_devx real_num_tx_queues pid: 21024、tid: 21024、reg_state
    2 netdev_rx_handler_unregister 伺服器 real_num_tx_queues1、cpu 9、pid 21024、tid 21024、reg_state2 synchronize_rcu_expeditedcpu 9、pid 21024、tid 21024 netdev_rx_handler_unregister ret 伺服器
    real_num_tx_queues1、cpu 9、pid 21024、tid 21024、reg_state2 dp_ ---truncated--- (CVE-2023-53188)

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

ID	Name	Product	Family	Published	Updated	Severity
265046	Linux Distros Unpatched Vulnerability : CVE-2023-53188	Nessus	Misc.	9/16/2025	9/30/2025	medium
265046	Linux Distros 未修补的漏洞：CVE-2023-53188	Nessus	Misc.	9/16/2025	9/30/2025	medium
265046	Linux Distros のパッチ未適用の脆弱性: CVE-2023-53188	Nessus	Misc.	9/16/2025	9/30/2025	medium
265046	Linux Distros 未修補的弱點：CVE-2023-53188	Nessus	Misc.	9/16/2025	9/30/2025	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium