In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsThere is no fixed version for Centos:9
kernel-rt-64k-devel-matched
.
Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-devel-matched
package and not the kernel-rt-64k-devel-matched
package as distributed by Centos
.
See How to fix?
for Centos:9
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix race on port output
assume the following setup on a single machine:
when following the actions below the host has a chance of getting a cpu stuck in a infinite loop:
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:
unregister_netdevice_many_notify
somewhere in the processNETREG_UNREGISTERING
on both ends of the veth and
then runs synchronize_net
call_netdevice_notifiers
with NETDEV_UNREGISTER
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)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 pathunregister_netdevice_many_notify
continues to call
netdev_unregister_kobject
which sets real_num_tx_queues
to 0If 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---