Always save ofport #6

ahill00 · 2014-07-18T17:00:11Z

No description provided.

Not saving the ofport on kmod reloads can lead to datapath outages with some scenarios. Further, there doesn't seem to be a reason not to save ofports.

Otherwise creating the first dpif-netdev bridge fails because there are no handlers: Program terminated with signal 8, Arithmetic exception. #0 0x080971e9 in dp_execute_cb (aux_=aux_@entry=0xffcfaa54, packet=packet@entry=0xffcfac54, md=md@entry=0xffcfac84, a=a@entry=0x8f58930, may_steal=false) at ../lib/dpif-netdev.c:2154 #1 0x080b5adb in odp_execute_actions__ (dp=dp@entry=0xffcfaa54, packet=packet@entry=0xffcfac54, steal=steal@entry=false, md=md@entry=0xffcfac84, actions=actions@entry=0x8f58930, actions_len=actions_len@entry=20, dp_execute_action=dp_execute_action@entry=0x8097040 <dp_execute_cb>, more_actions=more_actions@entry=false) at ../lib/odp-execute.c:218 #2 0x080b5def in odp_execute_actions (dp=dp@entry=0xffcfaa54, packet=packet@entry=0xffcfac54, steal=steal@entry=false, md=md@entry=0xffcfac84, actions=0x8f58930, actions_len=20, dp_execute_action=dp_execute_action@entry=0x8097040 <dp_execute_cb>) at ../lib/odp-execute.c:285 #3 0x08095098 in dp_netdev_execute_actions (actions_len=<optimized out>, actions=<optimized out>, md=0xffcfac84, may_steal=false, packet=0xffcfac54, key=0xffcfaa5c, dp=<optimized out>) at ../lib/dpif-netdev.c:2227 #4 dpif_netdev_execute (dpif=0x8f59598, execute=0xffcfac78) at ../lib/dpif-netdev.c:1551 #5 0x0809a56c in dpif_execute (dpif=0x8f59598, execute=execute@entry=0xffcfac78) at ../lib/dpif.c:1227 #6 0x08071071 in check_variable_length_userdata (backer=<optimized out>) at ../ofproto/ofproto-dpif.c:1040 #7 open_dpif_backer (backerp=0x8f5834c, type=<optimized out>) at ../ofproto/ofproto-dpif.c:921 #8 construct (ofproto_=0x8f581c0) at ../ofproto/ofproto-dpif.c:1120 #9 0x080675e0 in ofproto_create (datapath_name=0x8f57310 "br0", datapath_type=<optimized out>, ofprotop=ofprotop@entry=0x8f576c8) at ../ofproto/ofproto.c:564 #10 0x080529aa in bridge_reconfigure (ovs_cfg=ovs_cfg@entry=0x8f596d8) at ../vswitchd/bridge.c:572 #11 0x08055e33 in bridge_run () at ../vswitchd/bridge.c:2339 #12 0x0804cdbd in main (argc=9, argv=0xffcfb554) at ../vswitchd/ovs-vswitchd.c:116 This bug was introduced by commit 9bcefb9 (ofproto-dpif: fix an ovs crash when dpif_recv_set returns error). CC: Andy Zhou <[email protected]> Signed-off-by: Ben Pfaff <[email protected]> Acked-by: Justin Pettit <[email protected]>

This reverts commit 337bebe, which caused a crash in test 1048 "ofproto-dpif - Flow IPFIX sanity check" (now test 1051) with the following backtrace: #0 hmap_first_with_hash (hmap=<optimized out>, hmap=<optimized out>, hash=<optimized out>) at ../lib/hmap.h:328 #1 smap_find__ (smap=0x94, key=key@entry=0x817f7ab "virtual_obs_id", key_len=14, hash=2537071222) at ../lib/smap.c:366 #2 0x0812b9d7 in smap_get_node (smap=0x9738a276, key=0x817f7ab "virtual_obs_id") at ../lib/smap.c:198 #3 0x0812ba30 in smap_get (smap=0x94, key=0x817f7ab "virtual_obs_id") at ../lib/smap.c:189 #4 0x08055a60 in bridge_configure_ipfix (br=<optimized out>) at ../vswitchd/bridge.c:1237 #5 bridge_reconfigure (ovs_cfg=0x94) at ../vswitchd/bridge.c:666 #6 0x080568d3 in bridge_run () at ../vswitchd/bridge.c:2972 #7 0x0804c9dd in main (argc=10, argv=0xffd8b934) at ../vswitchd/ovs-vswitchd.c:112 Signed-off-by: Ben Pfaff <[email protected]>

This reverts commit 337bebe, which caused a crash in test 1048 "ofproto-dpif - Flow IPFIX sanity check" (now test 1051) with the following backtrace: #0 hmap_first_with_hash (hmap=<optimized out>, hmap=<optimized out>, hash=<optimized out>) at ../lib/hmap.h:328 openvswitch#1 smap_find__ (smap=0x94, key=key@entry=0x817f7ab "virtual_obs_id", key_len=14, hash=2537071222) at ../lib/smap.c:366 openvswitch#2 0x0812b9d7 in smap_get_node (smap=0x9738a276, key=0x817f7ab "virtual_obs_id") at ../lib/smap.c:198 openvswitch#3 0x0812ba30 in smap_get (smap=0x94, key=0x817f7ab "virtual_obs_id") at ../lib/smap.c:189 #4 0x08055a60 in bridge_configure_ipfix (br=<optimized out>) at ../vswitchd/bridge.c:1237 #5 bridge_reconfigure (ovs_cfg=0x94) at ../vswitchd/bridge.c:666 openvswitch#6 0x080568d3 in bridge_run () at ../vswitchd/bridge.c:2972 #7 0x0804c9dd in main (argc=10, argv=0xffd8b934) at ../vswitchd/ovs-vswitchd.c:112 Signed-off-by: Ben Pfaff <[email protected]>

This patch sets *typep to an empty string instead of letting it uninitialized when no QoS configuration is set. It fixes the following vswitchd crash when no QoS has been set on vhost-user interface: $> ovs-appctl -t ovs-vswitchd qos/show vhost-user1 #0 0x00007efcbadf18d7 in raise () from /lib64/libc.so.6 #1 0x00007efcbadf353a in abort () from /lib64/libc.so.6 #2 0x000000000068d5be in ovs_abort_valist at lib/util.c:335 #3 0x0000000000693d90 in vlog_abort_valist at lib/vlog.c:1204 #4 0x0000000000693e17 in vlog_abort at lib/vlog.c:1218 #5 0x000000000068d3ae in ovs_assert_failure at lib/util.c:72 #6 0x000000000060425c in ds_put_format_valist at lib/dynamic-string.c:168 #7 0x00000000006042e7 in ds_put_format at lib/dynamic-string.c:142 #8 0x00000000005a9e75 in qos_unixctl_show at vswitchd/bridge.c:3185 #9 0x000000000068cda1 in process_command at lib/unixctl.c:347 #11 unixctl_server_run at lib/unixctl.c:400 #12 0x000000000040a3ff in main at vswitchd/ovs-vswitchd.c:113 Signed-off-by: Maxime Coquelin <[email protected]> Acked-by: Ian Stokes <[email protected]> Signed-off-by: Daniele Di Proietto <[email protected]>

The newly added replication logic makes it possible for a monitor to receive delete and insertion of the same row back to back, which was not possible before. Add logic (and comment) to handle this case to avoid follow crash reported by Valgrind: #0 0x0000000000453edd in ovsdb_datum_compare_3way (a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1626 #1 0x0000000000453ea4 in ovsdb_datum_equals (a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1616 #2 0x000000000041b651 in update_monitor_row_data (mt=0x5eda4a0, row=0x5efbe00, data=0x0) at ovsdb/monitor.c:310 #3 0x000000000041ed14 in ovsdb_monitor_changes_update (old=0x0, new=0x5efbe00, mt=0x5eda4a0, changes=0x5ef7180) at ovsdb/monitor.c:1255 #4 0x000000000041f12e in ovsdb_monitor_change_cb (old=0x0, new=0x5efbe00, changed=0x5efc218, aux_=0xffefff040) at ovsdb/monitor.c:1339 #5 0x000000000042ded9 in ovsdb_txn_for_each_change (txn=0x5efbd90, cb=0x41ef50 <ovsdb_monitor_change_cb>, aux=0xffefff040) at ovsdb/transaction.c:906 #6 0x0000000000420155 in ovsdb_monitor_commit (replica=0x5eda2c0, txn=0x5efbd90, durable=false) at ovsdb/monitor.c:1553 #7 0x000000000042dc04 in ovsdb_txn_commit_ (txn=0x5efbd90, durable=false) at ovsdb/transaction.c:868 #8 0x000000000042ddd4 in ovsdb_txn_commit (txn=0x5efbd90, durable=false) at ovsdb/transaction.c:893 #9 0x0000000000422e0c in process_notification (table_updates=0x5efad10, db=0x5e6bd40) at ovsdb/replication.c:575 #10 0x0000000000420ff3 in replication_run () at ovsdb/replication.c:184 #11 0x0000000000405cc8 in main_loop (jsonrpc=0x5e67770, all_dbs=0xffefff3a0, unixctl=0x5ebd980, remotes=0xffefff360, run_process=0x0, exiting=0xffefff3c0, is_backup=0xffefff2de) at ovsdb/ovsdb-server.c:198 #12 0x0000000000406edb in main (argc=1, argv=0xffefff550) at ovsdb/ovsdb-server.c:429 Reported-by: Joe Stringer <[email protected]> Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079315.html Reported-by: Alin Serdean <[email protected]> Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079586.html Co-authored-by: Joe Stringer <[email protected]> Signed-off-by: Andy Zhou <[email protected]> Acked-by: Ben Pfaff <[email protected]>

dp_netdev_get_pmd() is allowed to return NULL (even if we call it with NON_PMD_CORE_ID) for different reasons: * Since we use RCU to protect pmd threads, it is possible that ovs_refcount_try_ref_rcu() has failed. * During reconfiguration we destroy every thread. This commit makes sure that we always handle the case when dp_netdev_get_pmd() returns NULL without crashing. This actually fixes a pretty serious crash that happens if dpif_netdev_execute() is called from a non pmd thread while reconfiguration is happening. It can be triggered by enabling bfd (because it's handled by the monitor thread, which is a non pmd thread) on an interface and changing something that requires datapath reconfiguration (n_rxq, pmd-cpu-mask). A testcase that reproduces the race condition is included. This is a possible backtrace of the segfault: #0 0x000000000060c7f1 in dp_execute_cb (aux_=0x7f1dd2d2a320, packets_=0x7f1dd2d2a370, a=0x7f1dd2d2a658, may_steal=false) at ../lib/dpif-netdev.c:4357 #1 0x00000000006448b2 in odp_execute_actions (dp=0x7f1dd2d2a320, batch=0x7f1dd2d2a370, steal=false, actions=0x7f1dd2d2a658, actions_len=8, dp_execute_action=0x60c7a5 <dp_execute_cb>) at ../lib/odp-execute.c:538 #2 0x000000000060d00c in dp_netdev_execute_actions (pmd=0x0, packets=0x7f1dd2d2a370, may_steal=false, flow=0x7f1dd2d2ae70, actions=0x7f1dd2d2a658, actions_len=8, now=44965873) at ../lib/dpif-netdev.c:4577 #3 0x000000000060834a in dpif_netdev_execute (dpif=0x2b67b70, execute=0x7f1dd2d2a578) at ../lib/dpif-netdev.c:2624 #4 0x0000000000608441 in dpif_netdev_operate (dpif=0x2b67b70, ops=0x7f1dd2d2a5c8, n_ops=1) at ../lib/dpif-netdev.c:2654 #5 0x0000000000610a30 in dpif_operate (dpif=0x2b67b70, ops=0x7f1dd2d2a5c8, n_ops=1) at ../lib/dpif.c:1268 #6 0x000000000061098c in dpif_execute (dpif=0x2b67b70, execute=0x7f1dd2d2aa50) at ../lib/dpif.c:1233 #7 0x00000000005b9008 in ofproto_dpif_execute_actions__ (ofproto=0x2b69360, version=18446744073709551614, flow=0x7f1dd2d2ae70, rule=0x0, ofpacts=0x7f1dd2d2b100, ofpacts_len=16, indentation=0, depth=0, resubmits=0, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:3806 #8 0x00000000005b907a in ofproto_dpif_execute_actions (ofproto=0x2b69360, version=18446744073709551614, flow=0x7f1dd2d2ae70, rule=0x0, ofpacts=0x7f1dd2d2b100, ofpacts_len=16, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:3823 #9 0x00000000005dea9b in xlate_send_packet (ofport=0x2b98380, oam=false, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif-xlate.c:5792 #10 0x00000000005bab12 in ofproto_dpif_send_packet (ofport=0x2b98380, oam=false, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:4628 #11 0x00000000005c3fc8 in monitor_mport_run (mport=0x2b8cd00, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif-monitor.c:287 #12 0x00000000005c3d9b in monitor_run () at ../ofproto/ofproto-dpif-monitor.c:227 #13 0x00000000005c3cab in monitor_main (args=0x0) at ../ofproto/ofproto-dpif-monitor.c:189 #14 0x00000000006a183a in ovsthread_wrapper (aux_=0x2b8afd0) at ../lib/ovs-thread.c:342 #15 0x00007f1dd75eb444 in start_thread (arg=0x7f1dd2d2c700) at pthread_create.c:333 #16 0x00007f1dd6e1d20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Signed-off-by: Daniele Di Proietto <[email protected]> Acked-by: Ben Pfaff <[email protected]>

dp_netdev_get_pmd() is allowed to return NULL (even if we call it with NON_PMD_CORE_ID) for different reasons: * Since we use RCU to protect pmd threads, it is possible that ovs_refcount_try_ref_rcu() has failed. * During reconfiguration we destroy every thread. This commit makes sure that we always handle the case when dp_netdev_get_pmd() returns NULL without crashing (the change in dpif_netdev_run() doesn't fix anything, because everything is happening in the main thread, but it's better to honor the interface in case we change our threading model). This actually fixes a pretty serious crash that happens if dpif_netdev_execute() is called from a non pmd thread while reconfiguration is happening. It can be triggered by enabling bfd (because it's handled by the monitor thread, which is a non pmd thread) on an interface and changing something that requires datapath reconfiguration (n_rxq, pmd-cpu-mask, mtu). A testcase that reproduces the race condition is included. This is a possible backtrace of the segfault: #0 0x000000000060c7f1 in dp_execute_cb (aux_=0x7f1dd2d2a320, packets_=0x7f1dd2d2a370, a=0x7f1dd2d2a658, may_steal=false) at ../lib/dpif-netdev.c:4357 #1 0x00000000006448b2 in odp_execute_actions (dp=0x7f1dd2d2a320, batch=0x7f1dd2d2a370, steal=false, actions=0x7f1dd2d2a658, actions_len=8, dp_execute_action=0x60c7a5 <dp_execute_cb>) at ../lib/odp-execute.c:538 #2 0x000000000060d00c in dp_netdev_execute_actions (pmd=0x0, packets=0x7f1dd2d2a370, may_steal=false, flow=0x7f1dd2d2ae70, actions=0x7f1dd2d2a658, actions_len=8, now=44965873) at ../lib/dpif-netdev.c:4577 #3 0x000000000060834a in dpif_netdev_execute (dpif=0x2b67b70, execute=0x7f1dd2d2a578) at ../lib/dpif-netdev.c:2624 #4 0x0000000000608441 in dpif_netdev_operate (dpif=0x2b67b70, ops=0x7f1dd2d2a5c8, n_ops=1) at ../lib/dpif-netdev.c:2654 #5 0x0000000000610a30 in dpif_operate (dpif=0x2b67b70, ops=0x7f1dd2d2a5c8, n_ops=1) at ../lib/dpif.c:1268 #6 0x000000000061098c in dpif_execute (dpif=0x2b67b70, execute=0x7f1dd2d2aa50) at ../lib/dpif.c:1233 #7 0x00000000005b9008 in ofproto_dpif_execute_actions__ (ofproto=0x2b69360, version=18446744073709551614, flow=0x7f1dd2d2ae70, rule=0x0, ofpacts=0x7f1dd2d2b100, ofpacts_len=16, indentation=0, depth=0, resubmits=0, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:3806 #8 0x00000000005b907a in ofproto_dpif_execute_actions (ofproto=0x2b69360, version=18446744073709551614, flow=0x7f1dd2d2ae70, rule=0x0, ofpacts=0x7f1dd2d2b100, ofpacts_len=16, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:3823 #9 0x00000000005dea9b in xlate_send_packet (ofport=0x2b98380, oam=false, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif-xlate.c:5792 #10 0x00000000005bab12 in ofproto_dpif_send_packet (ofport=0x2b98380, oam=false, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif.c:4628 #11 0x00000000005c3fc8 in monitor_mport_run (mport=0x2b8cd00, packet=0x7f1dd2d2b5c0) at ../ofproto/ofproto-dpif-monitor.c:287 #12 0x00000000005c3d9b in monitor_run () at ../ofproto/ofproto-dpif-monitor.c:227 #13 0x00000000005c3cab in monitor_main (args=0x0) at ../ofproto/ofproto-dpif-monitor.c:189 #14 0x00000000006a183a in ovsthread_wrapper (aux_=0x2b8afd0) at ../lib/ovs-thread.c:342 #15 0x00007f1dd75eb444 in start_thread (arg=0x7f1dd2d2c700) at pthread_create.c:333 #16 0x00007f1dd6e1d20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Signed-off-by: Daniele Di Proietto <[email protected]> Acked-by: Ben Pfaff <[email protected]>

When the datapath, whose type is "netdev", processes packets in userspce action, it may cause a segmentation fault. In the dp_execute_userspace_action(), we pass the "wc" argument to dp_netdev_upcall() using NULL. In the dp_netdev_upcall() call tree, the "wc" will be used. For example, dp_netdev_upcall() uses the &wc->masks for debugging, and flow_wildcards_init_for_packet() uses the "wc" if we disable megaflow, which is described in more detail below. Segmentation fault in flow_wildcards_init_for_packet: #0 0x0000000000468fe8 flow_wildcards_init_for_packet lib/flow.c:1275 #1 0x0000000000436c0b upcall_cb ofproto/ofproto-dpif-upcall.c:1231 #2 0x000000000045bd96 dp_netdev_upcall lib/dpif-netdev.c:3857 #3 0x0000000000461bf3 dp_execute_userspace_action lib/dpif-netdev.c:4388 #4 dp_execute_cb lib/dpif-netdev.c:4521 #5 0x0000000000486ae2 odp_execute_actions lib/odp-execute.c:538 #6 0x00000000004607f9 dp_netdev_execute_actions lib/dpif-netdev.c:4627 #7 packet_batch_per_flow_execute lib/dpif-netdev.c:3927 #8 dp_netdev_input__ lib/dpif-netdev.c:4229 #9 0x0000000000460ba8 dp_netdev_input lib/dpif-netdev.c:4238 #10 dp_netdev_process_rxq_port lib/dpif-netdev.c:2873 #11 0x000000000046126e dpif_netdev_run lib/dpif-netdev.c:3000 #12 0x000000000042baf5 type_run ofproto/ofproto-dpif.c:504 #13 0x00000000004192bf ofproto_type_run ofproto/ofproto.c:1687 #14 0x0000000000409965 bridge_run__ vswitchd/bridge.c:2875 #15 0x000000000040f145 bridge_run vswitchd/bridge.c:2938 #16 0x00000000004062e5 main vswitchd/ovs-vswitchd.c:111 Signed-off-by: nickcooper-zhangtonghao <[email protected]> Signed-off-by: Daniele Di Proietto <[email protected]>

nx_put_match() needs a non-NULL tunnel metadata table, otherwise it will crash if a flow matches on tunnel metadata. This wasn't handled in ofputil_append_flow_update(), causing a crash when the controller sent a flow monitor request. To fix the problem, this commit changes ofputil_append_flow_update() to behave like ofputil_append_flow_stats_reply(). Since ofputil_append_flow_update() now needs to temporarily modify the match, this commits also embeds 'struct match' into 'struct ofputil_flow_update', to be safer. This is more similar to 'struct ofputil_flow_stats'. A regression test is added and a comment is updated in ovs-ofctl.c #0 0x000055699bd82fa0 in memcpy_from_metadata (dst=0x7ffc770930d0, src=0x7ffc77093698, loc=0x18) at ../lib/tun-metadata.c:451 #1 0x000055699bd83c2e in metadata_loc_from_match_read (map=0x0, match=0x7ffc77093410, idx=0, mask=0x7ffc77093658, is_masked=0x7ffc77093287) at ../lib/tun-metadata.c:848 #2 0x000055699bd83d9b in tun_metadata_to_nx_match (b=0x55699d3f0300, oxm=0, match=0x7ffc77093410) at ../lib/tun-metadata.c:871 #3 0x000055699bce523d in nx_put_raw (b=0x55699d3f0300, oxm=0, match=0x7ffc77093410, cookie=0, cookie_mask=0) at ../lib/nx-match.c:1052 #4 0x000055699bce5580 in nx_put_match (b=0x55699d3f0300, match=0x7ffc77093410, cookie=0, cookie_mask=0) at ../lib/nx-match.c:1116 #5 0x000055699bd3926f in ofputil_append_flow_update (update=0x7ffc770940b0, replies=0x7ffc77094e00) at ../lib/ofp-util.c:6805 #6 0x000055699bc4b5a9 in ofproto_compose_flow_refresh_update (rule=0x55699d405b40, flags=(NXFMF_INITIAL | NXFMF_ACTIONS), msgs=0x7ffc77094e00) at ../ofproto/ofproto.c:5915 #7 0x000055699bc4b5f6 in ofmonitor_compose_refresh_updates (rules=0x7ffc77094e10, msgs=0x7ffc77094e00) at ../ofproto/ofproto.c:5929 #8 0x000055699bc4bafc in handle_flow_monitor_request (ofconn=0x55699d404090, oh=0x55699d404220) at ../ofproto/ofproto.c:6082 #9 0x000055699bc4f46d in handle_openflow__ (ofconn=0x55699d404090, msg=0x55699d404910) at ../ofproto/ofproto.c:7912 #10 0x000055699bc4f5df in handle_openflow (ofconn=0x55699d404090, ofp_msg=0x55699d404910) at ../ofproto/ofproto.c:8002 #11 0x000055699bc88154 in ofconn_run (ofconn=0x55699d404090, handle_openflow=0x55699bc4f5bc <handle_openflow>) at ../ofproto/connmgr.c:1427 #12 0x000055699bc85934 in connmgr_run (mgr=0x55699d3adb90, handle_openflow=0x55699bc4f5bc <handle_openflow>) at ../ofproto/connmgr.c:363 #13 0x000055699bc422c9 in ofproto_run (p=0x55699d3c85e0) at ../ofproto/ofproto.c:1798 #14 0x000055699bc31ec6 in bridge_run__ () at ../vswitchd/bridge.c:2881 #15 0x000055699bc320a6 in bridge_run () at ../vswitchd/bridge.c:2938 #16 0x000055699bc3784e in main (argc=10, argv=0x7ffc770952c8) at ../vswitchd/ovs-vswitchd.c:111 Fixes: 8d8ab6c ("tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis.") Signed-off-by: Daniele Di Proietto <[email protected]> Acked-by: Ben Pfaff <[email protected]>

revalidator_sweep__() splits checking for whether to delete a ukey from the actual deletion to prevent taking the umap lock for too long. However it uses information gathered from the first critical section to decide to call ukey_delete() - ie, the second critical section. Since 67f0898 ("upcall: Replace ukeys for deleted flows."), it is possible for a handler thread to receive an upcall for the same flow and to replace the ukey which is being deleted with a new one, in between these critical sections. This will remove the ukey from the cmap, rcu-defer its deletion, and update the ukey state. If this occurs in between the critical sections of revalidator cleanup of the flow, then the revalidator will subsequently call ukey_delete() to delete the original ukey, which was already deleted by the handler thread. This leads to a segfault in cmap_replace__(). Guard against this by checking the ukey state in ukey_delete() while holding the ukey lock. Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x00007fe969b13da3 in cmap_replace__ () #1 0x00007fe969b14491 in cmap_replace () #2 0x00007fe969aee9ff in ukey_delete () #3 0x00007fe969aefd42 in revalidator_sweep__ () #4 0x00007fe969af1bad in udpif_revalidator () #5 0x00007fe969b8b2a6 in ovsthread_wrapper () #6 0x00007fe968e07dc5 in start_thread () from /lib64/libpthread.so.0 #7 0x00007fe96862c73d in clone () from /lib64/libc.so.6 Fixes: 54ebeff ("upcall: Track ukey states.") Fixes: 67f0898 ("upcall: Replace ukeys for deleted flows.") Reported-by: Numan Siddique <[email protected]> Signed-off-by: Joe Stringer <[email protected]> Acked-by: Jarno Rajahalme <[email protected]>

When we use the 'ovs-appctl ofproto/trace' to send packets, which include the 'vlan' field, but exclude the 'encap', the ovs-vswitchd will crash. We should check 'encap' field in parse_8021q_onward(), before using it. ovs-appctl ofproto/trace ovs-system \ 'in_port(1),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:07), eth_type(0x8100),vlan(vid=99,pcp=0)' #0 nl_attr_get_size (nla=nla@entry=0x0) at lib/netlink.c:567 #1 parse_8021q_onward (src_flow=0x7ffd0ec77540, key_len=40, key=0x1207e00, flow=0x7ffd0ec77540, expected_attrs=<optimized out>, out_of_range_attr=0, present_attrs=120, attrs=0x7ffd0ec77170) at lib/odp-util.c:5359 #2 odp_flow_key_to_flow__ (key=0x1207e00, key_len=40, flow=flow@entry=0x7ffd0ec77540, src_flow=src_flow@entry=0x7ffd0ec77540) at lib/odp-util.c:5520 #3 odp_flow_key_to_flow (key=<optimized out>, key_len=<optimized out>, flow=flow@entry=0x7ffd0ec77540) at lib/odp-util.c:5555 #4 parse_flow_and_packet (argc=3, argv=0x12b2220, ofprotop=ofprotop@entry=0x7ffd0ec77510, flow=flow@entry=0x7ffd0ec77540, packetp=packetp@entry=0x7ffd0ec77518) at ofproto/ofproto-dpif-trace.c:211 #5 ofproto_unixctl_trace (conn=0x1268c20, argc=<optimized out>, argv=<optimized out>, aux=<optimized out>) at ofproto/ofproto-dpif-trace.c:309 #6 process_command (request=<optimized out>, conn=0x1268c20) at lib/unixctl.c:313 #7 run_connection (conn=0x1268c20) at lib/unixctl.c:347 #8 unixctl_server_run (server=0x1180970) at lib/unixctl.c:400 #9 main (argc=5, argv=0x7ffd0ec779c8) at vswitchd/ovs-vswitchd.c:120 Signed-off-by: nickcooper-zhangtonghao <[email protected]> Acked-by: Eric Garver <[email protected]> Signed-off-by: Joe Stringer <[email protected]>

Pulling fixes

There is a coredump when I add and delete bridges. When the rcu thread call ofproto_destroy__, the main thread may call ofproto_create. But the ofproto_destroy__ fun doesn't have the ofproto_mutex when access the all_ofprotos. #0 0x00007f824aa0d197 in raise () from /usr/lib64/libc.so.6 #1 0x00007f824aa0e888 in abort () from /usr/lib64/libc.so.6 #2 0x0000000000658249 in PAT_abort () #3 0x000000000065538d in patchIllInsHandler () #4 <signal handler called> #5 0x0000000000478a5b in hmap_remove (node=0x3320150, hmap=0x95fc40 <all_ofprotos>) at include/openvswitch/hmap.h:287 #6 ofproto_destroy__ (ofproto=0x3320150) at ofproto/ofproto.c:1642 #7 0x0000000000535e46 in ovsrcu_call_postponed () at lib/ovs_rcu.c:323 #8 0x0000000000536014 in ovsrcu_postpone_thread (arg=<optimized out>) at lib/ovs_rcu.c:338 #9 0x0000000000538488 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs_thread.c:682 #10 0x00007f824c130dc5 in start_thread () from /usr/lib64/libpthread.so.0 #11 0x00007f824aacf7bd in clone () from /usr/lib64/libc.so.6 Signed-off-by: Cheng Liu <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>

There is a coredump when I add and delete bridges. When the rcu thread call ofproto_destroy__, the main thread may call ofproto_create. But the ofproto_destroy__ fun doesn't have the ofproto_mutex when access the all_ofprotos. #0 0x00007f824aa0d197 in raise () from /usr/lib64/libc.so.6 openvswitch#1 0x00007f824aa0e888 in abort () from /usr/lib64/libc.so.6 openvswitch#2 0x0000000000658249 in PAT_abort () openvswitch#3 0x000000000065538d in patchIllInsHandler () #4 <signal handler called> #5 0x0000000000478a5b in hmap_remove (node=0x3320150, hmap=0x95fc40 <all_ofprotos>) at include/openvswitch/hmap.h:287 openvswitch#6 ofproto_destroy__ (ofproto=0x3320150) at ofproto/ofproto.c:1642 #7 0x0000000000535e46 in ovsrcu_call_postponed () at lib/ovs_rcu.c:323 #8 0x0000000000536014 in ovsrcu_postpone_thread (arg=<optimized out>) at lib/ovs_rcu.c:338 #9 0x0000000000538488 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs_thread.c:682 #10 0x00007f824c130dc5 in start_thread () from /usr/lib64/libpthread.so.0 #11 0x00007f824aacf7bd in clone () from /usr/lib64/libc.so.6 Signed-off-by: Cheng Liu <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>

Delete $config_file

New DDlog string syntax and internals

Problem Description: The ovs-vswitchd is crashing while invoking flow-mod with upsupported action(Tested with ovs2.10.1) Steps to recreate: Step 1) Create a flow ovs-ofctl add-flow switch1 priority=228,dl_type=0x0800,dl_vlan="600",in_port=25,actions=output:ALL This step is successful. Step 2) Invoke flow-mod with incorrect contents. ovs-ofctl mod-flows switch1 priority=228,dl_type=0x0800,dl_vlan="600",in_port=25,actions=output:ALL,mod_vlan_vid:50,mod_vlan_pcp=6,mod_nw_tos=16 In the above example, the ofproto provider I have, will return error for rule_construct as set_fields come after Output. However the OVS is ignoring the error (The return value of add_flow_init is ignored in modify_flow_init_strict) and eventually the ovs-vswitched crashes. Crash backtrace: ----------------------- Thread 1 "ovs-vswitchd" received signal SIGSEGV, Segmentation fault. 0x00007f6a06e785fb in modify_flows_start__ ( ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:5402 5402 in ofproto/ofproto.c (gdb) bt #0 0x00007f6a06e785fb in modify_flows_start__ ( ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:5402 #1 0x00007f6a06e790db in modify_flows_start_loose (ofm=0x7ffdf7d57b70, ofproto=0x55b289cecc28) at ofproto/ofproto.c:5443 #2 ofproto_flow_mod_start (ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:7672 #3 0x00007f6a06e79164 in handle_flow_mod__ ( ofproto=ofproto@entry=0x55b289cecc28, fm=fm@entry=0x7ffdf7d57d20, req=req@entry=0x7ffdf7d57cd0) at ofproto/ofproto.c:5858 #4 0x00007f6a06e792c2 in handle_flow_mod (ofconn=ofconn@entry =0x55b289d528c0, oh=oh@entry=0x55b289d5a410) at ofproto/ofproto.c:5835 #5 0x00007f6a06e7a173 in handle_openflow__ (msg=0x55b289d351d0, ofconn=0x55b289d528c0) at ofproto/ofproto.c:8127 #6 handle_openflow (ofconn=0x55b289d528c0, ofp_msg=0x55b289d351d0) at ofproto/ofproto.c:8296 #7 0x00007f6a06e6a013 in ofconn_run ( handle_openflow=0x7f6a06e796f0 <handle_openflow>, ofconn=0x55b289d528c0) at ofproto/connmgr.c:1446 #8 connmgr_run (mgr=0x55b289d14fe0, handle_openflow=handle_openflow@entry=0x7f6a06e796f0 handle_openflow>) at ofproto/connmgr.c:365 With this fix, OVS does not crash. Signed-off-by: Parameswaran Krishnamurthy <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>

After inserting/removing a bucket, we don't update the bucket counter. When we call ovs-ofctl dump-group-stats br-int, a panic happened. Reproduce steps: 1. ovs-ofctl -O OpenFlow15 add-group br-int "group_id=1, type=select, selection_method=hash bucket=bucket_id=1,weight:100,actions=output:1" 2. ovs-ofctl insert-buckets br-int "group_id=1, command_bucket_id=last, bucket=bucket_id=7,weight:800,actions=output:1" 3. ovs-ofctl dump-group-stats br-int gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 openvswitch#1 0x00007f028675b42a in __GI_abort () at abort.c:89 openvswitch#2 0x00007f0286797c00 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f028688cd98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 openvswitch#3 0x00007f028679dfc6 in malloc_printerr (action=3, str=0x7f028688cea8 "free(): invalid next size (fast)", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049 #4 0x00007f028679e80e in _int_free (av=0x7f0286ac0b00 <main_arena>, p=0x55cac2920040, have_lock=0) at malloc.c:3905 #5 0x000055cab8fd6d8e in append_group_stats (group=0x55cac250d860, replies=0x7fffe6a11b90) at ofproto/ofproto.c:6770 openvswitch#6 0x000055cab8fd8d04 in handle_group_request (ofconn=ofconn@entry=0x55cac28ec5a0, request=request@entry=0x55cac29317f0, group_id=<optimized out>, cb=cb@entry=0x55cab8fd6cd0 <append_group_stats>) at ofproto/ofproto.c:6790 #7 0x000055cab8fe2a96 in handle_group_stats_request (request=0x55cac29317f0, ofconn=0x55cac28ec5a0) at ofproto/ofproto.c:6815 #8 handle_openflow__ (msg=0x55cac29365c0, ofconn=0x55cac28ec5a0) at ofproto/ofproto.c:8282 #9 handle_openflow (ofconn=0x55cac28ec5a0, ofp_msg=0x55cac29365c0) at ofproto/ofproto.c:8362 #10 0x000055cab9013ddb in ofconn_run (handle_openflow=0x55cab8fe23c0 <handle_openflow>, ofconn=0x55cac28ec5a0) at ofproto/connmgr.c:1446 #11 connmgr_run (mgr=0x55cabb2ce360, handle_openflow=handle_openflow@entry=0x55cab8fe23c0 <handle_openflow>) at ofproto/connmgr.c:365 #12 0x000055cab8fdc516 in ofproto_run (p=0x55cabb2cddd0) at ofproto/ofproto.c:1825 #13 0x000055cab8fcabfc in bridge_run__ () at vswitchd/bridge.c:2944 #14 0x000055cab8fcfe64 in bridge_run () at vswitchd/bridge.c:3002 #15 0x000055cab8c693ed in main (argc=<optimized out>, argv=<optimized out>) at vswitchd/ovs-vswitchd.c:125 Signed-off-by: solomon <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Running ovsdb-server with empty private-key and non-empty certificate (or otherwise) causes crash: # ovsdb-tool create ./etc/openvswitch/conf.db ./vswitch.ovsschema # ovsdb-server --remote=punix:./db.sock \ --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ --private-key=db:Open_vSwitch,SSL,private_key \ --certificate=db:Open_vSwitch,SSL,certificate \ --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert # ovs-vsctl --no-wait init # ovs-vsctl --no-wait set-ssl pkey.key cert.cert ca.cert # ovs-vsctl --no-wait set SSL . private_key='""' # ovs-vsctl --no-wait set SSL . certificate='cert.new' ==25513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 ==25513==The signal is caused by a READ memory access. ==25513==Hint: address points to the zero page. #0 0x7ff7582aa0a9 in __GI___strlen_sse2 openvswitch#1 0x7ff759bdde81 (/lib64/libasan.so.5+0xace81) openvswitch#2 0x7ff759479932 (/lib64/libcrypto.so.1.1+0xb3932) openvswitch#3 0x7ff759473c5a in BIO_ctrl (/lib64/libcrypto.so.1.1+0xadc5a) #4 0x7ff7598decc1 in SSL_CTX_use_certificate_file (/lib64/libssl.so.1.1+0x40cc1) #5 0x4dbaa7 in stream_ssl_set_certificate_file__ lib/stream-ssl.c:1170 openvswitch#6 0x4dca2e in stream_ssl_set_key_and_cert lib/stream-ssl.c:1216 #7 0x4146b2 in reconfigure_ssl ovsdb/ovsdb-server.c:1254 #8 0x409c83 in main ovsdb/ovsdb-server.c:368 #9 0x7ff758233812 in __libc_start_main #10 0x40f6bd in _start (ovsdb-server+0x40f6bd) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x9a0a9) in __GI___strlen_sse2 ==25513==ABORTING Another way to reproduce is to use non-initialized DB entry for private-key and a file for certificate in ovsdb-server cmdline. The root cause is that stream_ssl_set_key_and_cert() triggers configuration for both key and cert if any of them is valid, keeping it possible for one of them to be NULL. Fixes: 6f1e91b ("stream-ssl: Make changing keys and certificate at runtime reliable.") Signed-off-by: Ilya Maximets <[email protected]>

Running ovsdb-server with empty private-key and non-empty certificate (or otherwise) causes crash: # ovsdb-tool create ./etc/openvswitch/conf.db ./vswitch.ovsschema # ovsdb-server --remote=punix:./db.sock \ --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ --private-key=db:Open_vSwitch,SSL,private_key \ --certificate=db:Open_vSwitch,SSL,certificate \ --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert # ovs-vsctl --no-wait init # ovs-vsctl --no-wait set-ssl pkey.key cert.cert ca.cert # ovs-vsctl --no-wait set SSL . private_key='""' # ovs-vsctl --no-wait set SSL . certificate='cert.new' ==25513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 ==25513==The signal is caused by a READ memory access. ==25513==Hint: address points to the zero page. #0 0x7ff7582aa0a9 in __GI___strlen_sse2 openvswitch#1 0x7ff759bdde81 (/lib64/libasan.so.5+0xace81) openvswitch#2 0x7ff759479932 (/lib64/libcrypto.so.1.1+0xb3932) openvswitch#3 0x7ff759473c5a in BIO_ctrl (/lib64/libcrypto.so.1.1+0xadc5a) #4 0x7ff7598decc1 in SSL_CTX_use_certificate_file (/lib64/libssl.so.1.1+0x40cc1) #5 0x4dbaa7 in stream_ssl_set_certificate_file__ lib/stream-ssl.c:1170 openvswitch#6 0x4dca2e in stream_ssl_set_key_and_cert lib/stream-ssl.c:1216 #7 0x4146b2 in reconfigure_ssl ovsdb/ovsdb-server.c:1254 #8 0x409c83 in main ovsdb/ovsdb-server.c:368 #9 0x7ff758233812 in __libc_start_main #10 0x40f6bd in _start (ovsdb-server+0x40f6bd) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x9a0a9) in __GI___strlen_sse2 ==25513==ABORTING Another way to reproduce is to use non-initialized DB entry for private-key and a file for certificate in ovsdb-server cmdline. The root cause is that stream_ssl_set_key_and_cert() triggers configuration for both key and cert if any of them is valid, keeping it possible for one of them to be NULL. Fixes: 6f1e91b ("stream-ssl: Make changing keys and certificate at runtime reliable.") Signed-off-by: Ilya Maximets <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Running ovsdb-server with empty private-key and non-empty certificate (or otherwise) causes crash: # ovsdb-tool create ./etc/openvswitch/conf.db ./vswitch.ovsschema # ovsdb-server --remote=punix:./db.sock \ --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ --private-key=db:Open_vSwitch,SSL,private_key \ --certificate=db:Open_vSwitch,SSL,certificate \ --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert # ovs-vsctl --no-wait init # ovs-vsctl --no-wait set-ssl pkey.key cert.cert ca.cert # ovs-vsctl --no-wait set SSL . private_key='""' # ovs-vsctl --no-wait set SSL . certificate='cert.new' ==25513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 ==25513==The signal is caused by a READ memory access. ==25513==Hint: address points to the zero page. #0 0x7ff7582aa0a9 in __GI___strlen_sse2 openvswitch#1 0x7ff759bdde81 (/lib64/libasan.so.5+0xace81) openvswitch#2 0x7ff759479932 (/lib64/libcrypto.so.1.1+0xb3932) openvswitch#3 0x7ff759473c5a in BIO_ctrl (/lib64/libcrypto.so.1.1+0xadc5a) #4 0x7ff7598decc1 in SSL_CTX_use_certificate_file (/lib64/libssl.so.1.1+0x40cc1) #5 0x4dbaa7 in stream_ssl_set_certificate_file__ lib/stream-ssl.c:1170 openvswitch#6 0x4dca2e in stream_ssl_set_key_and_cert lib/stream-ssl.c:1216 #7 0x4146b2 in reconfigure_ssl ovsdb/ovsdb-server.c:1254 #8 0x409c83 in main ovsdb/ovsdb-server.c:368 #9 0x7ff758233812 in __libc_start_main #10 0x40f6bd in _start (ovsdb-server+0x40f6bd) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x9a0a9) in __GI___strlen_sse2 ==25513==ABORTING Another way to reproduce is to use non-initialized DB entry for private-key and a file for certificate in ovsdb-server cmdline. The root cause is that stream_ssl_set_key_and_cert() triggers configuration for both key and cert if any of them is valid, keeping it possible for one of them to be NULL. Fixes: 6f1e91b ("stream-ssl: Make changing keys and certificate at runtime reliable.") Signed-off-by: Ilya Maximets <[email protected]> Acked-by: Ben Pfaff <[email protected]>

Running ovsdb-server with empty private-key and non-empty certificate (or otherwise) causes crash: # ovsdb-tool create ./etc/openvswitch/conf.db ./vswitch.ovsschema # ovsdb-server --remote=punix:./db.sock \ --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ --private-key=db:Open_vSwitch,SSL,private_key \ --certificate=db:Open_vSwitch,SSL,certificate \ --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert # ovs-vsctl --no-wait init # ovs-vsctl --no-wait set-ssl pkey.key cert.cert ca.cert # ovs-vsctl --no-wait set SSL . private_key='""' # ovs-vsctl --no-wait set SSL . certificate='cert.new' ==25513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 ==25513==The signal is caused by a READ memory access. ==25513==Hint: address points to the zero page. #0 0x7ff7582aa0a9 in __GI___strlen_sse2 #1 0x7ff759bdde81 (/lib64/libasan.so.5+0xace81) #2 0x7ff759479932 (/lib64/libcrypto.so.1.1+0xb3932) #3 0x7ff759473c5a in BIO_ctrl (/lib64/libcrypto.so.1.1+0xadc5a) #4 0x7ff7598decc1 in SSL_CTX_use_certificate_file (/lib64/libssl.so.1.1+0x40cc1) #5 0x4dbaa7 in stream_ssl_set_certificate_file__ lib/stream-ssl.c:1170 #6 0x4dca2e in stream_ssl_set_key_and_cert lib/stream-ssl.c:1216 #7 0x4146b2 in reconfigure_ssl ovsdb/ovsdb-server.c:1254 #8 0x409c83 in main ovsdb/ovsdb-server.c:368 #9 0x7ff758233812 in __libc_start_main #10 0x40f6bd in _start (ovsdb-server+0x40f6bd) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x9a0a9) in __GI___strlen_sse2 ==25513==ABORTING Another way to reproduce is to use non-initialized DB entry for private-key and a file for certificate in ovsdb-server cmdline. The root cause is that stream_ssl_set_key_and_cert() triggers configuration for both key and cert if any of them is valid, keeping it possible for one of them to be NULL. Fixes: 6f1e91b ("stream-ssl: Make changing keys and certificate at runtime reliable.") Signed-off-by: Ilya Maximets <[email protected]> Acked-by: Ben Pfaff <[email protected]>

Direct leak of 36 byte(s) in 1 object(s) allocated from: #0 0x527d90 in __interceptor_realloc.part.0 asan_malloc_linux.cpp.o openvswitch#1 0xc5f9fc in xrealloc__ /workspace/ovs/lib/util.c:147:9 openvswitch#2 0xc5f9fc in xrealloc /workspace/ovs/lib/util.c:179:12 openvswitch#3 0x86845d in ds_reserve /workspace/ovs/lib/dynamic-string.c:63:22 #4 0x86954a in ds_put_format_valist /workspace/ovs/lib/dynamic-string.c:164:9 #5 0x869202 in ds_put_format /workspace/ovs/lib/dynamic-string.c:142:5 openvswitch#6 0x7dc664 in ct_dpif_parse_tuple /workspace/ovs/lib/ct-dpif.c #7 0xebb089 in dpctl_flush_conntrack /workspace/ovs/lib/dpctl.c:1717:17 #8 0xeb4eb2 in dpctl_unixctl_handler /workspace/ovs/lib/dpctl.c:3035:17 #9 0xc5d4f8 in process_command /workspace/ovs/lib/unixctl.c:310:13 #10 0xc5d4f8 in run_connection /workspace/ovs/lib/unixctl.c:344:17 #11 0xc5d4f8 in unixctl_server_run /workspace/ovs/lib/unixctl.c:395:21 #12 0x5a643f in main /workspace/ovs/vswitchd/ovs-vswitchd.c:130:9 Signed-off-by: Ales Musil <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

The OpenFlow15 Packet-Out message contains the whole match instead of the in_port. The match has no assignment but used in oxm_put_match. The coredump gdb backtrace is: #0 memcpy_from_metadata (dst=dst@entry=0x7ffcfac2f060, src=src@entry=0x7ffcfac30880, loc=loc@entry=0x10) at lib/tun-metadata.c:467 openvswitch#1 0x00000000004506e8 in metadata_loc_from_match_read (match=0x7ffcfac30598, is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, map=0x0) at lib/tun-metadata.c:865 openvswitch#2 metadata_loc_from_match_read (is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, match=0x7ffcfac30598, map=0x0) at lib/tun-metadata.c:854 openvswitch#3 tun_metadata_to_nx_match (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598) at lib/tun-metadata.c:888 #4 0x000000000047c1f8 in nx_put_raw (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598, cookie=<optimized out>, cookie@entry=0, cookie_mask=<optimized out>, cookie_mask@entry=0) at lib/nx-match.c:1186 #5 0x000000000047d693 in oxm_put_match (b=b@entry=0x892260, match=match@entry=0x7ffcfac30598, version=version@entry=OFP15_VERSION) at lib/nx-match.c:1343 openvswitch#6 0x000000000043194e in ofputil_encode_packet_out (po=po@entry=0x7ffcfac30580, protocol=<optimized out>) at lib/ofp-packet.c:1226 #7 0x000000000040a4fe in process_packet_in (sw=sw@entry=0x891d70, oh=<optimized out>) at lib/learning-switch.c:619 #8 0x000000000040acdc in lswitch_process_packet (msg=0x892210, sw=0x891d70) at lib/learning-switch.c:374 #9 lswitch_run (sw=0x891d70) at lib/learning-switch.c:324 #10 0x0000000000406f26 in main (argc=<optimized out>, argv=<optimized out>) at utilities/ovs-testcontroller.c:180 Fix that by setting the packet-out match instead of in_port. Fixes: 577bfa9 ("ofp-util: Add OpenFlow 1.5 packet-out support") Signed-off-by: Faicker Mo <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

The OpenFlow15 Packet-Out message contains the match instead of the in_port. The flow.tunnel.metadata.tab is not inited but used in the loop of tun_metadata_to_nx_match. The coredump gdb backtrace is: #0 memcpy_from_metadata (dst=dst@entry=0x7ffcfac2f060, src=src@entry=0x7ffcfac30880, loc=loc@entry=0x10) at lib/tun-metadata.c:467 openvswitch#1 0x00000000004506e8 in metadata_loc_from_match_read (match=0x7ffcfac30598, is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, map=0x0) at lib/tun-metadata.c:865 openvswitch#2 metadata_loc_from_match_read (is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, match=0x7ffcfac30598, map=0x0) at lib/tun-metadata.c:854 openvswitch#3 tun_metadata_to_nx_match (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598) at lib/tun-metadata.c:888 #4 0x000000000047c1f8 in nx_put_raw (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598, cookie=<optimized out>, cookie@entry=0, cookie_mask=<optimized out>, cookie_mask@entry=0) at lib/nx-match.c:1186 #5 0x000000000047d693 in oxm_put_match (b=b@entry=0x892260, match=match@entry=0x7ffcfac30598, version=version@entry=OFP15_VERSION) at lib/nx-match.c:1343 openvswitch#6 0x000000000043194e in ofputil_encode_packet_out (po=po@entry=0x7ffcfac30580, protocol=<optimized out>) at lib/ofp-packet.c:1226 #7 0x000000000040a4fe in process_packet_in (sw=sw@entry=0x891d70, oh=<optimized out>) at lib/learning-switch.c:619 #8 0x000000000040acdc in lswitch_process_packet (msg=0x892210, sw=0x891d70) at lib/learning-switch.c:374 #9 lswitch_run (sw=0x891d70) at lib/learning-switch.c:324 #10 0x0000000000406f26 in main (argc=<optimized out>, argv=<optimized out>) at utilities/ovs-testcontroller.c:180 Fix that by zeroing out the po variable. Fixes: 577bfa9 ("ofp-util: Add OpenFlow 1.5 packet-out support") Signed-off-by: Faicker Mo <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

The OpenFlow15 Packet-Out message contains the match instead of the in_port. The flow.tunnel.metadata.tab is not inited but used in the loop of tun_metadata_to_nx_match. The coredump gdb backtrace is: #0 memcpy_from_metadata (dst=dst@entry=0x7ffcfac2f060, src=src@entry=0x7ffcfac30880, loc=loc@entry=0x10) at lib/tun-metadata.c:467 openvswitch#1 0x00000000004506e8 in metadata_loc_from_match_read (match=0x7ffcfac30598, is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, map=0x0) at lib/tun-metadata.c:865 openvswitch#2 metadata_loc_from_match_read (is_masked=<synthetic pointer>, mask=0x7ffcfac30838, idx=0, match=0x7ffcfac30598, map=0x0) at lib/tun-metadata.c:854 openvswitch#3 tun_metadata_to_nx_match (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598) at lib/tun-metadata.c:888 #4 0x000000000047c1f8 in nx_put_raw (b=b@entry=0x892260, oxm=oxm@entry=OFP15_VERSION, match=match@entry=0x7ffcfac30598, cookie=<optimized out>, cookie@entry=0, cookie_mask=<optimized out>, cookie_mask@entry=0) at lib/nx-match.c:1186 #5 0x000000000047d693 in oxm_put_match (b=b@entry=0x892260, match=match@entry=0x7ffcfac30598, version=version@entry=OFP15_VERSION) at lib/nx-match.c:1343 openvswitch#6 0x000000000043194e in ofputil_encode_packet_out (po=po@entry=0x7ffcfac30580, protocol=<optimized out>) at lib/ofp-packet.c:1226 #7 0x000000000040a4fe in process_packet_in (sw=sw@entry=0x891d70, oh=<optimized out>) at lib/learning-switch.c:619 #8 0x000000000040acdc in lswitch_process_packet (msg=0x892210, sw=0x891d70) at lib/learning-switch.c:374 #9 lswitch_run (sw=0x891d70) at lib/learning-switch.c:324 #10 0x0000000000406f26 in main (argc=<optimized out>, argv=<optimized out>) at utilities/ovs-testcontroller.c:180 Fix that by initing the flow metadata. Fixes: 35eb632 ("ofp-util: Add flow metadata to ofputil_packet_out") Signed-off-by: Faicker Mo <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Reported by Address Sanitizer. Indirect leak of 1024 byte(s) in 1 object(s) allocated from: #0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8759be in xmalloc__ lib/util.c:140 openvswitch#2 0x875a9a in xmalloc lib/util.c:175 openvswitch#3 0x7ba0d2 in ofpbuf_init lib/ofpbuf.c:141 #4 0x7ba1d6 in ofpbuf_new lib/ofpbuf.c:169 #5 0x9057f9 in nl_sock_transact lib/netlink-socket.c:1113 openvswitch#6 0x907a7e in nl_transact lib/netlink-socket.c:1817 #7 0x8b5abe in dpif_netlink_dp_transact lib/dpif-netlink.c:5007 #8 0x89a6b5 in dpif_netlink_open lib/dpif-netlink.c:398 #9 0x5de16f in do_open lib/dpif.c:348 #10 0x5de69a in dpif_open lib/dpif.c:393 #11 0x5de71f in dpif_create_and_open lib/dpif.c:419 #12 0x47b918 in open_dpif_backer ofproto/ofproto-dpif.c:764 #13 0x483e4a in construct ofproto/ofproto-dpif.c:1658 #14 0x441644 in ofproto_create ofproto/ofproto.c:556 #15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885 openvswitch#16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 openvswitch#18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: b841e3c ("dpif-netlink: Fix feature negotiation for older kernels.") Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Currently, bundle->cvlans and xbundle->cvlans are pointing to the same memory location. This can cause issues if the main thread modifies bundle->cvlans and frees it while the revalidator thread is still accessing xbundle->cvlans. This can result in use after free errors. AddressSanitizer: heap-use-after-free on address 0x615000007b08 at pc 0x0000004ede1e bp 0x7f3120ee0310 sp 0x7f3120ee0300 READ of size 8 at 0x615000007b08 thread T25 (revalidator25) #0 0x4ede1d in bitmap_is_set lib/bitmap.h:91 openvswitch#1 0x4fcb26 in xbundle_allows_cvlan ofproto/ofproto-dpif-xlate.c:2028 openvswitch#2 0x4fe279 in input_vid_is_valid ofproto/ofproto-dpif-xlate.c:2294 openvswitch#3 0x502abf in xlate_normal ofproto/ofproto-dpif-xlate.c:3051 #4 0x5164dc in xlate_output_action ofproto/ofproto-dpif-xlate.c:5361 #5 0x522576 in do_xlate_actions ofproto/ofproto-dpif-xlate.c:7047 openvswitch#6 0x52a751 in xlate_actions ofproto/ofproto-dpif-xlate.c:8061 #7 0x4e2b66 in xlate_key ofproto/ofproto-dpif-upcall.c:2212 #8 0x4e2e13 in xlate_ukey ofproto/ofproto-dpif-upcall.c:2227 #9 0x4e345d in revalidate_ukey__ ofproto/ofproto-dpif-upcall.c:2276 #10 0x4e3f85 in revalidate_ukey ofproto/ofproto-dpif-upcall.c:2395 #11 0x4e7ac5 in revalidate ofproto/ofproto-dpif-upcall.c:2858 #12 0x4d9ed3 in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1010 #13 0x7cd92e in ovsthread_wrapper lib/ovs-thread.c:423 #14 0x7f312ff01f3a (/usr/lib64/libpthread.so.0+0x8f3a) #15 0x7f312fc8f51f in clone (/usr/lib64/libc.so.6+0xf851f) 0x615000007b08 is located 8 bytes inside of 512-byte region [0x615000007b00,0x615000007d00) freed by thread T0 here: #0 0x7f3130378ad8 in free (/usr/lib64/libasan.so.4+0xe0ad8) openvswitch#1 0x49044e in bundle_set ofproto/ofproto-dpif.c:3431 openvswitch#2 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 openvswitch#3 0x40e6c9 in port_configure vswitchd/bridge.c:1300 #4 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 #5 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 openvswitch#6 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 #7 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) previously allocated by thread T0 here: #0 0x7f3130378e70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8757fe in xmalloc__ lib/util.c:140 openvswitch#2 0x8758da in xmalloc lib/util.c:175 openvswitch#3 0x875927 in xmemdup lib/util.c:188 #4 0x475f63 in bitmap_clone lib/bitmap.h:79 #5 0x47797c in vlan_bitmap_clone lib/vlan-bitmap.h:40 openvswitch#6 0x49048d in bundle_set ofproto/ofproto-dpif.c:3433 #7 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 #8 0x40e6c9 in port_configure vswitchd/bridge.c:1300 #9 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 #10 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #11 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 #12 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: fed8962 ("Add new port VLAN mode "dot1q-tunnel"") Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Reported by Address Sanitizer. Indirect leak of 1024 byte(s) in 1 object(s) allocated from: #0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8759be in xmalloc__ lib/util.c:140 openvswitch#2 0x875a9a in xmalloc lib/util.c:175 openvswitch#3 0x7ba0d2 in ofpbuf_init lib/ofpbuf.c:141 #4 0x7ba1d6 in ofpbuf_new lib/ofpbuf.c:169 #5 0x9057f9 in nl_sock_transact lib/netlink-socket.c:1113 openvswitch#6 0x907a7e in nl_transact lib/netlink-socket.c:1817 #7 0x8b5abe in dpif_netlink_dp_transact lib/dpif-netlink.c:5007 #8 0x89a6b5 in dpif_netlink_open lib/dpif-netlink.c:398 #9 0x5de16f in do_open lib/dpif.c:348 #10 0x5de69a in dpif_open lib/dpif.c:393 #11 0x5de71f in dpif_create_and_open lib/dpif.c:419 #12 0x47b918 in open_dpif_backer ofproto/ofproto-dpif.c:764 #13 0x483e4a in construct ofproto/ofproto-dpif.c:1658 #14 0x441644 in ofproto_create ofproto/ofproto.c:556 #15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885 openvswitch#16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 openvswitch#18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: b841e3c ("dpif-netlink: Fix feature negotiation for older kernels.") Suggested-by: David Marchand <[email protected]> Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

In the specific call to dpif_netlink_dp_transact() (line 398) in dpif_netlink_open(), the 'dp' content is not being used in the branch when no error is returned (starting line 430). Furthermore, the 'dp' and 'buf' variables are overwritten later in this same branch when a new netlink request is sent (line 437), which results in a memory leak. Reported by Address Sanitizer. Indirect leak of 1024 byte(s) in 1 object(s) allocated from: #0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8759be in xmalloc__ lib/util.c:140 openvswitch#2 0x875a9a in xmalloc lib/util.c:175 openvswitch#3 0x7ba0d2 in ofpbuf_init lib/ofpbuf.c:141 #4 0x7ba1d6 in ofpbuf_new lib/ofpbuf.c:169 #5 0x9057f9 in nl_sock_transact lib/netlink-socket.c:1113 openvswitch#6 0x907a7e in nl_transact lib/netlink-socket.c:1817 #7 0x8b5abe in dpif_netlink_dp_transact lib/dpif-netlink.c:5007 #8 0x89a6b5 in dpif_netlink_open lib/dpif-netlink.c:398 #9 0x5de16f in do_open lib/dpif.c:348 #10 0x5de69a in dpif_open lib/dpif.c:393 #11 0x5de71f in dpif_create_and_open lib/dpif.c:419 #12 0x47b918 in open_dpif_backer ofproto/ofproto-dpif.c:764 #13 0x483e4a in construct ofproto/ofproto-dpif.c:1658 #14 0x441644 in ofproto_create ofproto/ofproto.c:556 #15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885 openvswitch#16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 openvswitch#18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: b841e3c ("dpif-netlink: Fix feature negotiation for older kernels.") Suggested-by: David Marchand <[email protected]> Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

In the specific call to dpif_netlink_dp_transact() (line 398) in dpif_netlink_open(), the 'dp' content is not being used in the branch when no error is returned (starting line 430). Furthermore, the 'dp' and 'buf' variables are overwritten later in this same branch when a new netlink request is sent (line 437), which results in a memory leak. Reported by Address Sanitizer. Indirect leak of 1024 byte(s) in 1 object(s) allocated from: #0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8759be in xmalloc__ lib/util.c:140 openvswitch#2 0x875a9a in xmalloc lib/util.c:175 openvswitch#3 0x7ba0d2 in ofpbuf_init lib/ofpbuf.c:141 #4 0x7ba1d6 in ofpbuf_new lib/ofpbuf.c:169 #5 0x9057f9 in nl_sock_transact lib/netlink-socket.c:1113 openvswitch#6 0x907a7e in nl_transact lib/netlink-socket.c:1817 #7 0x8b5abe in dpif_netlink_dp_transact lib/dpif-netlink.c:5007 #8 0x89a6b5 in dpif_netlink_open lib/dpif-netlink.c:398 #9 0x5de16f in do_open lib/dpif.c:348 #10 0x5de69a in dpif_open lib/dpif.c:393 #11 0x5de71f in dpif_create_and_open lib/dpif.c:419 #12 0x47b918 in open_dpif_backer ofproto/ofproto-dpif.c:764 #13 0x483e4a in construct ofproto/ofproto-dpif.c:1658 #14 0x441644 in ofproto_create ofproto/ofproto.c:556 #15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885 openvswitch#16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 openvswitch#18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: b841e3c ("dpif-netlink: Fix feature negotiation for older kernels.") Reviewed-by: David Marchand <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Currently, bundle->cvlans and xbundle->cvlans are pointing to the same memory location. This can cause issues if the main thread modifies bundle->cvlans and frees it while the revalidator thread is still accessing xbundle->cvlans. This leads to use-after-free error. AddressSanitizer: heap-use-after-free on address 0x615000007b08 at pc 0x0000004ede1e bp 0x7f3120ee0310 sp 0x7f3120ee0300 READ of size 8 at 0x615000007b08 thread T25 (revalidator25) #0 0x4ede1d in bitmap_is_set lib/bitmap.h:91 openvswitch#1 0x4fcb26 in xbundle_allows_cvlan ofproto/ofproto-dpif-xlate.c:2028 openvswitch#2 0x4fe279 in input_vid_is_valid ofproto/ofproto-dpif-xlate.c:2294 openvswitch#3 0x502abf in xlate_normal ofproto/ofproto-dpif-xlate.c:3051 #4 0x5164dc in xlate_output_action ofproto/ofproto-dpif-xlate.c:5361 #5 0x522576 in do_xlate_actions ofproto/ofproto-dpif-xlate.c:7047 openvswitch#6 0x52a751 in xlate_actions ofproto/ofproto-dpif-xlate.c:8061 #7 0x4e2b66 in xlate_key ofproto/ofproto-dpif-upcall.c:2212 #8 0x4e2e13 in xlate_ukey ofproto/ofproto-dpif-upcall.c:2227 #9 0x4e345d in revalidate_ukey__ ofproto/ofproto-dpif-upcall.c:2276 #10 0x4e3f85 in revalidate_ukey ofproto/ofproto-dpif-upcall.c:2395 #11 0x4e7ac5 in revalidate ofproto/ofproto-dpif-upcall.c:2858 #12 0x4d9ed3 in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1010 #13 0x7cd92e in ovsthread_wrapper lib/ovs-thread.c:423 #14 0x7f312ff01f3a (/usr/lib64/libpthread.so.0+0x8f3a) #15 0x7f312fc8f51f in clone (/usr/lib64/libc.so.6+0xf851f) 0x615000007b08 is located 8 bytes inside of 512-byte region [0x615000007b00,0x615000007d00) freed by thread T0 here: #0 0x7f3130378ad8 in free (/usr/lib64/libasan.so.4+0xe0ad8) openvswitch#1 0x49044e in bundle_set ofproto/ofproto-dpif.c:3431 openvswitch#2 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 openvswitch#3 0x40e6c9 in port_configure vswitchd/bridge.c:1300 #4 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 #5 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 openvswitch#6 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 #7 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) previously allocated by thread T0 here: #0 0x7f3130378e70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70) openvswitch#1 0x8757fe in xmalloc__ lib/util.c:140 openvswitch#2 0x8758da in xmalloc lib/util.c:175 openvswitch#3 0x875927 in xmemdup lib/util.c:188 #4 0x475f63 in bitmap_clone lib/bitmap.h:79 #5 0x47797c in vlan_bitmap_clone lib/vlan-bitmap.h:40 openvswitch#6 0x49048d in bundle_set ofproto/ofproto-dpif.c:3433 #7 0x444f92 in ofproto_bundle_register ofproto/ofproto.c:1455 #8 0x40e6c9 in port_configure vswitchd/bridge.c:1300 #9 0x40bcfd in bridge_reconfigure vswitchd/bridge.c:921 #10 0x41f1a9 in bridge_run vswitchd/bridge.c:3313 #11 0x42d4fb in main vswitchd/ovs-vswitchd.c:132 #12 0x7f312fbbcc86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86) Fixes: fed8962 ("Add new port VLAN mode "dot1q-tunnel"") Signed-off-by: Yunjian Wang <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Found by AddressSanitizer when running OVN tests: Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x498fb2 in calloc (/ic/ovn-ic+0x498fb2) openvswitch#1 0x5f681e in xcalloc__ ovs/lib/util.c:121:31 openvswitch#2 0x5f681e in xzalloc__ ovs/lib/util.c:131:12 openvswitch#3 0x5f681e in xzalloc ovs/lib/util.c:165:12 #4 0x5e3697 in ovsdb_idl_txn_add_map_op ovs/lib/ovsdb-idl.c:4057:29 #5 0x4d3f25 in update_isb_pb_external_ids ic/ovn-ic.c:576:5 openvswitch#6 0x4cc4cc in create_isb_pb ic/ovn-ic.c:716:5 #7 0x4cc4cc in port_binding_run ic/ovn-ic.c:803:21 #8 0x4cc4cc in ovn_db_run ic/ovn-ic.c:1700:5 #9 0x4c9c1c in main ic/ovn-ic.c:1984:17 #10 0x7f9ad9f4a0b2 in __libc_start_main Signed-off-by: Dumitru Ceara <[email protected]> Signed-off-by: Ilya Maximets <[email protected]>

OVN unit tests highlight this: ERROR: LeakSanitizer: detected memory leaks Direct leak of 1344 byte(s) in 1 object(s) allocated from: #0 0x4db0b7 in calloc (/root/master-ovn/ovs/ovsdb/ovsdb-server+0x4db0b7) openvswitch#1 0x5c2162 in xcalloc__ /root/master-ovn/ovs/lib/util.c:124:31 openvswitch#2 0x5c221c in xcalloc /root/master-ovn/ovs/lib/util.c:161:12 openvswitch#3 0x54afbc in ovsdb_condition_diff /root/master-ovn/ovs/ovsdb/condition.c:527:21 #4 0x529da6 in ovsdb_monitor_table_condition_update /root/master-ovn/ovs/ovsdb/monitor.c:824:5 #5 0x524fa4 in ovsdb_jsonrpc_parse_monitor_cond_change_request /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:1557:13 openvswitch#6 0x5235c3 in ovsdb_jsonrpc_monitor_cond_change /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:1624:25 #7 0x5217f2 in ovsdb_jsonrpc_session_got_request /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:1034:17 #8 0x520ee6 in ovsdb_jsonrpc_session_run /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:572:17 #9 0x51ffbe in ovsdb_jsonrpc_session_run_all /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:602:21 #10 0x51fbcf in ovsdb_jsonrpc_server_run /root/master-ovn/ovs/ovsdb/jsonrpc-server.c:417:9 #11 0x517550 in main_loop /root/master-ovn/ovs/ovsdb/ovsdb-server.c:224:9 #12 0x512e80 in main /root/master-ovn/ovs/ovsdb/ovsdb-server.c:507:5 #13 0x7f9ecf675b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) Signed-off-by: Xavier Simonart <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

This avoids misaligned accesses as flagged by UBSan when running CoPP system tests: controller/pinctrl.c:7129:28: runtime error: member access within misaligned address 0x61b0000627be for type 'const struct bfd_msg', which requires 4 byte alignment 0x61b0000627be: note: pointer points here 00 20 d3 d4 20 60 05 18 a8 99 e7 7b 92 1d 36 73 00 0f 42 40 00 0f 42 40 00 00 00 00 00 00 00 03 ^ #0 0x621b8f in pinctrl_check_bfd_msg /root/ovn/controller/pinctrl.c:7129:28 openvswitch#1 0x621b8f in pinctrl_handle_bfd_msg /root/ovn/controller/pinctrl.c:7183:10 openvswitch#2 0x621b8f in process_packet_in /root/ovn/controller/pinctrl.c:3320:9 openvswitch#3 0x621b8f in pinctrl_recv /root/ovn/controller/pinctrl.c:3386:9 #4 0x621b8f in pinctrl_handler /root/ovn/controller/pinctrl.c:3481:17 #5 0xa2d89a in ovsthread_wrapper /root/ovn/ovs/lib/ovs-thread.c:422:12 openvswitch#6 0x7fcb598081ce in start_thread (/lib64/libpthread.so.0+0x81ce) #7 0x7fcb58439dd2 in clone (/lib64/libc.so.6+0x39dd2) Fixes: 1172035 ("controller: introduce BFD tx path in ovn-controller.") Reported-by: Ilya Maximets <[email protected]> Acked-by: Ales Musil <[email protected]> Signed-off-by: Dumitru Ceara <[email protected]>

Nothing is being freed wherever we are calling ctl_fatal which is fine because the program is about to shutdown anyway however one of the leaks was caught by address sanitizer. Fix most of the leaks that are happening before call to ctl_fatal. Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x568d70 in __interceptor_realloc.part.0 asan_malloc_linux.cpp.o openvswitch#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9 openvswitch#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12 openvswitch#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12 #4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23 #5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5 openvswitch#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5 #7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20 #8 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12 Indirect leak of 10 byte(s) in 1 object(s) allocated from: #0 0x569c07 in malloc (/workspace/ovn/utilities/ovn-nbctl+0x569c07) (BuildId: 3a287416f70de43f52382f0336980c876f655f90) openvswitch#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15 openvswitch#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12 openvswitch#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15 #4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27 #5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5 openvswitch#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20 #7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12 Indirect leak of 8 byte(s) in 2 object(s) allocated from: #0 0x569c07 in malloc (/workspace/ovn/utilities/ovn-nbctl+0x569c07) openvswitch#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15 openvswitch#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12 openvswitch#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15 #4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27 #5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9 openvswitch#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20 #7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12 Signed-off-by: Ales Musil <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Dumitru Ceara <[email protected]>

…eletion. When multiple LSP deletions are handled in incremental processing, if it hits a LSP that can't be incrementally processed after incrementally processing some LSP deletions, it falls back to recompute without destroying the ovn_port objects that are already handled in the handler, resulting in memory leaks. See example below, which is detected by the new test case added by this patch when running with address sanitizer. ======================= Indirect leak of 936 byte(s) in 3 object(s) allocated from: #0 0x55bce7 in calloc (/home/hanzhou/src/ovn/_build_as/northd/ovn-northd+0x55bce7) openvswitch#1 0x773f4e in xcalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:121:31 openvswitch#2 0x773f4e in xzalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:131:12 openvswitch#3 0x773f4e in xzalloc /home/hanzhou/src/ovs/_build/../lib/util.c:165:12 #4 0x60106c in en_northd_run /home/hanzhou/src/ovn/_build_as/../northd/en-northd.c:137:5 #5 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5 openvswitch#6 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17 #7 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14 #8 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9 #9 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9 #10 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33 #11 0x7f473933c1a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) Indirect leak of 204 byte(s) in 3 object(s) allocated from: #0 0x55bea8 in realloc (/home/hanzhou/src/ovn/_build_as/northd/ovn-northd+0x55bea8) openvswitch#1 0x773c7d in xrealloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:147:9 openvswitch#2 0x773c7d in xrealloc /home/hanzhou/src/ovs/_build/../lib/util.c:179:12 openvswitch#3 0x614bd4 in extract_addresses /home/hanzhou/src/ovn/_build_as/../lib/ovn-util.c:228:12 #4 0x614bd4 in extract_lsp_addresses /home/hanzhou/src/ovn/_build_as/../lib/ovn-util.c:243:20 #5 0x5c8d90 in parse_lsp_addrs /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2468:21 openvswitch#6 0x5b2ebf in join_logical_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2594:13 #7 0x5b2ebf in build_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:4711:5 #8 0x5b2ebf in ovnnb_db_run /home/hanzhou/src/ovn/_build_as/../northd/northd.c:17376:5 #9 0x60106c in en_northd_run /home/hanzhou/src/ovn/_build_as/../northd/en-northd.c:137:5 #10 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5 #11 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17 #12 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14 #13 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9 #14 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9 #15 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33 openvswitch#16 0x7f473933c1a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) ... Fixes: b337750 ("northd: Incremental processing of VIF changes in 'northd' node.") Reported-by: Dumitru Ceara <[email protected]> Signed-off-by: Han Zhou <[email protected]> Acked-by: Dumitru Ceara <[email protected]>

It's specified in RFC 8415. This also avoids having to free/realloc the pfd->uuid.data memory. That part was not correct anyway and was flagged by ASAN as a memleak: Direct leak of 42 byte(s) in 3 object(s) allocated from: #0 0x55e5b6354c9e in malloc (/workspace/ovn-tmp/controller/ovn-controller+0x2edc9e) (BuildId: f963f8c756bd5a2207a9b3c922d4362e46bb3162) openvswitch#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15 openvswitch#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12 openvswitch#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20 #4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9 #5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9 openvswitch#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9 #7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17 #8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12 #9 0x7faa30194b42 (/lib/x86_64-linux-gnu/libc.so.6+0x94b42) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d) Fixes: faa44a0 ("controller: IPv6 Prefix-Delegation: introduce RENEW/REBIND msg support") Signed-off-by: Ales Musil <[email protected]> Co-authored-by: Ales Musil <[email protected]> Signed-off-by: Dumitru Ceara <[email protected]> Acked-by: Lorenzo Bianconi <[email protected]>

The new_buffer data pointer is NULL when the size of the cloned buffer is 0. This is fine as there is no need to allocate space. However, the clonned buffer header/msg might be the same pointer as data. Tis causes undefined behavior by adding 0 to NULL pointer. This was caught by OVN system test: lib/ofpbuf.c:203:56: runtime error: applying zero offset to null pointer #0 0xa012fc in ofpbuf_clone_with_headroom /workspace/ovn/ovs/lib/ofpbuf.c:203:56 #1 0x635fd4 in put_remote_port_redirect_overlay /workspace/ovn/controller/physical.c:397:40 openvswitch#2 0x635fd4 in consider_port_binding /workspace/ovn/controller/physical.c:1951:9 openvswitch#3 0x62e046 in physical_run /workspace/ovn/controller/physical.c:2447:9 #4 0x601d98 in en_pflow_output_run /workspace/ovn/controller/ovn-controller.c:4690:5 #5 0x707769 in engine_recompute /workspace/ovn/lib/inc-proc-eng.c:415:5 openvswitch#6 0x7060eb in engine_compute /workspace/ovn/lib/inc-proc-eng.c:454:17 #7 0x7060eb in engine_run_node /workspace/ovn/lib/inc-proc-eng.c:503:14 #8 0x7060eb in engine_run /workspace/ovn/lib/inc-proc-eng.c:528:9 #9 0x5f9f26 in main /workspace/ovn/controller/ovn-controller.c Signed-off-by: Ales Musil <[email protected]>

The new_buffer data pointer is NULL when the size of the cloned buffer is 0. This is fine as there is no need to allocate space. However, the cloned buffer header/msg might be the same pointer as data. This causes undefined behavior by adding 0 to NULL pointer. Check if the data buffer is not NULL before attempting to apply the header/msg offset. This was caught by OVN system test: lib/ofpbuf.c:203:56: runtime error: applying zero offset to null pointer #0 0xa012fc in ofpbuf_clone_with_headroom /workspace/ovn/ovs/lib/ofpbuf.c:203:56 #1 0x635fd4 in put_remote_port_redirect_overlay /workspace/ovn/controller/physical.c:397:40 openvswitch#2 0x635fd4 in consider_port_binding /workspace/ovn/controller/physical.c:1951:9 openvswitch#3 0x62e046 in physical_run /workspace/ovn/controller/physical.c:2447:9 #4 0x601d98 in en_pflow_output_run /workspace/ovn/controller/ovn-controller.c:4690:5 #5 0x707769 in engine_recompute /workspace/ovn/lib/inc-proc-eng.c:415:5 openvswitch#6 0x7060eb in engine_compute /workspace/ovn/lib/inc-proc-eng.c:454:17 #7 0x7060eb in engine_run_node /workspace/ovn/lib/inc-proc-eng.c:503:14 #8 0x7060eb in engine_run /workspace/ovn/lib/inc-proc-eng.c:528:9 #9 0x5f9f26 in main /workspace/ovn/controller/ovn-controller.c Signed-off-by: Ales Musil <[email protected]>

The new_buffer data pointer is NULL when the size of the cloned buffer is 0. This is fine as there is no need to allocate space. However, the cloned buffer header/msg might be the same pointer as data. This causes undefined behavior by adding 0 to NULL pointer. Check if the data buffer is not NULL before attempting to apply the header/msg offset. This was caught by OVN system test: lib/ofpbuf.c:203:56: runtime error: applying zero offset to null pointer #0 0xa012fc in ofpbuf_clone_with_headroom /workspace/ovn/ovs/lib/ofpbuf.c:203:56 openvswitch#1 0x635fd4 in put_remote_port_redirect_overlay /workspace/ovn/controller/physical.c:397:40 openvswitch#2 0x635fd4 in consider_port_binding /workspace/ovn/controller/physical.c:1951:9 openvswitch#3 0x62e046 in physical_run /workspace/ovn/controller/physical.c:2447:9 #4 0x601d98 in en_pflow_output_run /workspace/ovn/controller/ovn-controller.c:4690:5 #5 0x707769 in engine_recompute /workspace/ovn/lib/inc-proc-eng.c:415:5 openvswitch#6 0x7060eb in engine_compute /workspace/ovn/lib/inc-proc-eng.c:454:17 #7 0x7060eb in engine_run_node /workspace/ovn/lib/inc-proc-eng.c:503:14 #8 0x7060eb in engine_run /workspace/ovn/lib/inc-proc-eng.c:528:9 #9 0x5f9f26 in main /workspace/ovn/controller/ovn-controller.c Signed-off-by: Ales Musil <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

The has was passed to memcpy as uin32_t *, however the hash bytes might be unaligned at that point. Case it to uint8_t * instead which has only single byte alignment requirement. lib/hash.c:46:22: runtime error: load of misaligned address 0x507000000065 for type 'const uint32_t *' (aka 'const unsigned int *'), which requires 4 byte alignment 0x507000000065: note: pointer points here 73 62 2e 73 6f 63 6b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x6191cb in hash_bytes /workspace/ovn/ovs/lib/hash.c:46:9 #1 0x69d064 in hash_string /workspace/ovn/ovs/lib/hash.h:404:12 openvswitch#2 0x69d064 in hash_name /workspace/ovn/ovs/lib/shash.c:29:12 openvswitch#3 0x69d064 in shash_find /workspace/ovn/ovs/lib/shash.c:237:49 #4 0x69dada in shash_find_data /workspace/ovn/ovs/lib/shash.c:251:31 #5 0x507987 in add_remote /workspace/ovn/ovs/ovsdb/ovsdb-server.c:1382:15 openvswitch#6 0x507987 in parse_options /workspace/ovn/ovs/ovsdb/ovsdb-server.c:2659:13 #7 0x507987 in main /workspace/ovn/ovs/ovsdb/ovsdb-server.c:751:5 #8 0x7f47e3997087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) #9 0x7f47e399714a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) #10 0x42de64 in _start (/workspace/ovn/ovs/ovsdb/ovsdb-server+0x42de64) (BuildId: 6c3f4e311556b29f84c9c4a5d6df5114dc08a12e) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior lib/hash.c:46:22 Signed-off-by: Ales Musil <[email protected]>

The has was passed to memcpy as uin32_t *, however the hash bytes might be unaligned at that point. Case it to uint8_t * instead which has only single byte alignment requirement. lib/hash.c:46:22: runtime error: load of misaligned address 0x507000000065 for type 'const uint32_t *' (aka 'const unsigned int *'), which requires 4 byte alignment 0x507000000065: note: pointer points here 73 62 2e 73 6f 63 6b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x6191cb in hash_bytes /workspace/ovn/ovs/lib/hash.c:46:9 openvswitch#1 0x69d064 in hash_string /workspace/ovn/ovs/lib/hash.h:404:12 openvswitch#2 0x69d064 in hash_name /workspace/ovn/ovs/lib/shash.c:29:12 openvswitch#3 0x69d064 in shash_find /workspace/ovn/ovs/lib/shash.c:237:49 #4 0x69dada in shash_find_data /workspace/ovn/ovs/lib/shash.c:251:31 #5 0x507987 in add_remote /workspace/ovn/ovs/ovsdb/ovsdb-server.c:1382:15 openvswitch#6 0x507987 in parse_options /workspace/ovn/ovs/ovsdb/ovsdb-server.c:2659:13 #7 0x507987 in main /workspace/ovn/ovs/ovsdb/ovsdb-server.c:751:5 #8 0x7f47e3997087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) #9 0x7f47e399714a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) #10 0x42de64 in _start (/workspace/ovn/ovs/ovsdb/ovsdb-server+0x42de64) (BuildId: 6c3f4e311556b29f84c9c4a5d6df5114dc08a12e) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior lib/hash.c:46:22 Signed-off-by: Ales Musil <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

In function shash_replace_nocopy, argument to free() is the address of a global variable (argument passed by function table_print_json__), which is not memory allocated by malloc(). ovsdb-client -f json monitor Open_vSwitch --timestamp ASan reports: ================================================================= ==1443083==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000535980 in thread T0 #0 0xffffaf1c9eac in __interceptor_free (/usr/lib64/libasan.so.6+ 0xa4eac) openvswitch#1 0x4826e4 in json_destroy_object lib/json.c:445 openvswitch#2 0x4826e4 in json_destroy__ lib/json.c:403 openvswitch#3 0x4cc4e4 in table_print lib/table.c:633 #4 0x410650 in monitor_print_table ovsdb/ovsdb-client.c:1019 #5 0x410650 in monitor_print ovsdb/ovsdb-client.c:1040 openvswitch#6 0x4110cc in monitor_print ovsdb/ovsdb-client.c:1030 #7 0x4110cc in do_monitor__ ovsdb/ovsdb-client.c:1503 #8 0x40743c in main ovsdb/ovsdb-client.c:283 #9 0xffffaeb50038 (/usr/lib64/libc.so.6+0x2b038) #10 0xffffaeb50110 in __libc_start_main (/usr/lib64/libc.so.6+ 0x2b110) #11 0x40906c in _start (/usr/local/bin/ovsdb-client+0x40906c) Use xstrdup to allocate memory for argument "time". Fixes: cb139fa ("table: New function table_format() for formatting a table as a string.") Signed-off-by: Pengfei Sun <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

In function shash_replace_nocopy, argument to free() is the address of a global variable (argument passed by function table_print_json__), which is not memory allocated by malloc(). ovsdb-client -f json monitor Open_vSwitch --timestamp ASan reports: ================================================================= ==1443083==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000535980 in thread T0 #0 0xffffaf1c9eac in __interceptor_free (/usr/lib64/libasan.so.6+ 0xa4eac) openvswitch#1 0x4826e4 in json_destroy_object lib/json.c:445 openvswitch#2 0x4826e4 in json_destroy__ lib/json.c:403 openvswitch#3 0x4cc4e4 in table_print lib/table.c:633 #4 0x410650 in monitor_print_table ovsdb/ovsdb-client.c:1019 #5 0x410650 in monitor_print ovsdb/ovsdb-client.c:1040 openvswitch#6 0x4110cc in monitor_print ovsdb/ovsdb-client.c:1030 #7 0x4110cc in do_monitor__ ovsdb/ovsdb-client.c:1503 #8 0x40743c in main ovsdb/ovsdb-client.c:283 #9 0xffffaeb50038 (/usr/lib64/libc.so.6+0x2b038) #10 0xffffaeb50110 in __libc_start_main (/usr/lib64/libc.so.6+ 0x2b110) #11 0x40906c in _start (/usr/local/bin/ovsdb-client+0x40906c) Fixes: cb139fa ("table: New function table_format() for formatting a table as a string.") Signed-off-by: Pengfei Sun <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

When compiling with '-fsanitize=address,undefined', the "ovs-ofctl ct-flush" test will yield the following undefined behavior flagged by UBSan. This patch uses memcpy to move the 128bit value into the stack before reading it. lib/ofp-prop.c:277:14: runtime error: load of misaligned address for type 'union ovs_be128', which requires 8 byte alignment ^ #0 0x7735d4 in ofpprop_parse_u128 lib/ofp-prop.c:277 openvswitch#1 0x6c6c83 in ofp_ct_match_decode lib/ofp-ct.c:529 openvswitch#2 0x76f3b5 in ofp_print_nxt_ct_flush lib/ofp-print.c:959 openvswitch#3 0x76f3b5 in ofp_to_string__ lib/ofp-print.c:1206 #4 0x76f3b5 in ofp_to_string lib/ofp-print.c:1264 #5 0x770c0d in ofp_print lib/ofp-print.c:1308 openvswitch#6 0x484a9d in ofctl_ofp_print utilities/ovs-ofctl.c:4899 #7 0x4ddb77 in ovs_cmdl_run_command__ lib/command-line.c:247 #8 0x47f6b3 in main utilities/ovs-ofctl.c:186 Signed-off-by: Mike Pattrick <[email protected]>

When compiling with '-fsanitize=address,undefined', the "ovs-ofctl ct-flush" test will yield the following undefined behavior flagged by UBSan. This patch uses memcpy to move the 128bit value into the stack before reading it. lib/ofp-prop.c:277:14: runtime error: load of misaligned address for type 'union ovs_be128', which requires 8 byte alignment ^ #0 0x7735d4 in ofpprop_parse_u128 lib/ofp-prop.c:277 openvswitch#1 0x6c6c83 in ofp_ct_match_decode lib/ofp-ct.c:529 openvswitch#2 0x76f3b5 in ofp_print_nxt_ct_flush lib/ofp-print.c:959 openvswitch#3 0x76f3b5 in ofp_to_string__ lib/ofp-print.c:1206 #4 0x76f3b5 in ofp_to_string lib/ofp-print.c:1264 #5 0x770c0d in ofp_print lib/ofp-print.c:1308 openvswitch#6 0x484a9d in ofctl_ofp_print utilities/ovs-ofctl.c:4899 #7 0x4ddb77 in ovs_cmdl_run_command__ lib/command-line.c:247 #8 0x47f6b3 in main utilities/ovs-ofctl.c:186 Signed-off-by: Mike Pattrick <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior in lib/dpif-netlink.c:1077:40: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' #0 0x73fc31 in dpif_netlink_port_add_compat lib/dpif-netlink.c:1077:40 openvswitch#1 0x73fc31 in dpif_netlink_port_add lib/dpif-netlink.c:1132:17 openvswitch#2 0x2c1745 in dpif_port_add lib/dpif.c:597:13 openvswitch#3 0x07b279 in port_add ofproto/ofproto-dpif.c:3957:17 #4 0x01b209 in ofproto_port_add ofproto/ofproto.c:2124:13 #5 0xfdbfce in iface_do_create vswitchd/bridge.c:2066:13 openvswitch#6 0xfdbfce in iface_create vswitchd/bridge.c:2109:13 #7 0xfdbfce in bridge_add_ports__ vswitchd/bridge.c:1173:21 #8 0xfb5319 in bridge_add_ports vswitchd/bridge.c:1189:5 #9 0xfb5319 in bridge_reconfigure vswitchd/bridge.c:901:9 #10 0xfae0f9 in bridge_run vswitchd/bridge.c:3334:9 #11 0xfe67dd in main vswitchd/ovs-vswitchd.c:129:9 #12 0x4b6d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) #13 0x4b6e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) #14 0x562594eed024 in _start (vswitchd/ovs-vswitchd+0x787024) Fixes: 526df7d ("tunnel: Provide framework for tunnel extensions for VXLAN-GBP and others") Acked-by: Mike Pattrick <[email protected]> Signed-off-by: Ilya Maximets <[email protected]>

==ovs-vswitchd==217313==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffff8032c108 at pc 0xaaaae8056454 bp 0xffff764bedc0 sp 0xffff764bedb8 READ of size 8 at 0xffff8032c108 thread T10 #0 0xaaaae8056450 in system_port_watchdog_main /root/openvswitch/lib/dpif-netdev.c:1666:44 #1 0xaaaae86f6eb4 in ovsthread_wrapper /root/openvswitch/lib/ovs-thread.c:423:12 #2 0xffff835bd5c4 in start_thread nptl/./nptl/pthread_create.c:442:8 #3 0xffff83625ed8 misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79 0xffff8032c108 is located 8 bytes to the left of 16-byte region [0xffff8032c110,0xffff8032c120) allocated by thread T0 here: #0 0xaaaae78114fc in __interceptor_calloc (/usr/sbin/ovs-vswitchd+0xc914fc) (BuildId: ada031802bcaa5e55e1f80e86a59240452b972b9) #1 0xaaaae8900060 in xcalloc__ /root/openvswitch/lib/util.c:124:31 #2 0xaaaae8900138 in xzalloc__ /root/openvswitch/lib/util.c:134:12 #3 0xaaaae89004ac in xzalloc /root/openvswitch/lib/util.c:168:12 #4 0xaaaae8387598 in netdev_get_addrs /root/openvswitch/lib/netdev.c:2407:18 #5 0xaaaae89d4184 in netdev_linux_get_addr_list /root/openvswitch/lib/netdev-linux.c:3570:13 openvswitch#6 0xaaaae837e6c0 in netdev_get_addr_list /root/openvswitch/lib/netdev.c:1552:16 #7 0xaaaae88b7cd8 in insert_ipdev /root/openvswitch/lib/tnl-ports.c:438:13 #8 0xaaaae88b7590 in tnl_port_map_insert_ipdev /root/openvswitch/lib/tnl-ports.c:479:5 #9 0xaaaae86e82fc in ovs_router_insert__ /root/openvswitch/lib/ovs-router.c:316:5 #10 0xaaaae86e7938 in ovs_router_insert /root/openvswitch/lib/ovs-router.c:328:9 Use netdev_is_configured to see if the port is configured instead its internals. Signed-off-by: Eli Britstein <[email protected]> Change-Id: I740f0a0d17fa239ec637592d7b29fcd8ebc7c36b

Calls to ovs_fatal from check_ovsdb_error would trigger an asan splat in the ci. This is a harmless memory leak as the process would always immediately terminate anyways. ==245041==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 in malloc openvswitch#1 in xmalloc__ lib/util.c:141:15 openvswitch#2 in xmalloc lib/util.c:176:12 openvswitch#3 in ovsdb_error_valist lib/ovsdb-error.c:40:33 #4 in ovsdb_error lib/ovsdb-error.c:55:13 #5 in ovsdb_log_open ovsdb/log.c openvswitch#6 in do_db_name ovsdb/ovsdb-tool.c:482:23 #7 in ovs_cmdl_run_command__ lib/command-line.c:247:17 #8 in main ovsdb/ovsdb-tool.c:82:5 Signed-off-by: Mike Pattrick <[email protected]>

Calls to ovs_fatal from check_ovsdb_error would trigger an asan splat in the ci. This is a harmless memory leak as the process would always immediately terminate anyways. ==245041==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 in malloc openvswitch#1 in xmalloc__ lib/util.c:141:15 openvswitch#2 in xmalloc lib/util.c:176:12 openvswitch#3 in ovsdb_error_valist lib/ovsdb-error.c:40:33 #4 in ovsdb_error lib/ovsdb-error.c:55:13 #5 in ovsdb_log_open ovsdb/log.c openvswitch#6 in do_db_name ovsdb/ovsdb-tool.c:482:23 #7 in ovs_cmdl_run_command__ lib/command-line.c:247:17 #8 in main ovsdb/ovsdb-tool.c:82:5 Signed-off-by: Mike Pattrick <[email protected]> Signed-off-by: 0-day Robot <[email protected]>

Always save ofports

12e8467

Not saving the ofport on kmod reloads can lead to datapath outages with some scenarios. Further, there doesn't seem to be a reason not to save ofports.

ahill00 closed this Jul 18, 2014

kthkaya added a commit to kthkaya/ovs that referenced this pull request Apr 13, 2018

Merge pull request openvswitch#6 from kthkaya/TRFrameworkV3.2_Zoltan

99e4573

Pulling fixes

chenwhql added a commit to chenwhql/ovs that referenced this pull request Dec 22, 2018

Merge pull request openvswitch#6 from thurtsdn/yearsj-patch-1

b29dbac

Delete $config_file

justinpettit added a commit that referenced this pull request Mar 1, 2019

Merge pull request #6 from ryzhyk/ddlog

3729381

New DDlog string syntax and internals

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Always save ofport #6

Always save ofport #6

ahill00 commented Jul 18, 2014

Always save ofport #6

Always save ofport #6

Conversation

ahill00 commented Jul 18, 2014