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