CVE-2023-53188

*** 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-&gt;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---