FYI - The link to the Open vSwitch software tutorial is broken in your README.md. #7
Comments
|
Thanks for raising the issue. I will fix it. Thanks |
larsks
added a commit
to larsks/ovn
that referenced
this issue
Jan 11, 2020
This fixes the broken link in the README to the ovs-advanced tutorial. This also adds a hyperlink to Documentation/tutorials/ovn-sandbox.rst where the tutorial is referenced. Closes ovn-org#7
larsks
added a commit
to larsks/ovn
that referenced
this issue
Jan 11, 2020
This fixes the broken link in the README to the ovs-advanced tutorial. This also adds a hyperlink to Documentation/tutorials/ovn-sandbox.rst where the tutorial is referenced. Closes ovn-org#7
larsks
added a commit
to larsks/ovn
that referenced
this issue
Jan 11, 2020
This fixes the broken link in the README to the ovs-advanced tutorial. This also adds a hyperlink to Documentation/tutorials/ovn-sandbox.rst where the tutorial is referenced. Closes ovn-org#7
larsks
added a commit
to larsks/ovn
that referenced
this issue
Jan 13, 2020
This fixes the broken link in the README to the ovs-advanced tutorial. This also adds a hyperlink to Documentation/tutorials/ovn-sandbox.rst where the tutorial is referenced. Closes ovn-org#7 Signed-off-by: Lars Kellogg-Stedman <lars@redhat.com>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Oct 14, 2020
The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > ovn-org#1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > ovn-org#2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > ovn-org#3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > ovn-org#4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > ovn-org#5 0x51887b in main ic/ovn-ic.c:1674:17 > ovn-org#6 0x7fd4ce7871a2 in __libc_start_main > ovn-org#7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Signed-off-by: Han Zhou <hzhou@ovn.org> Signed-off-by: 0-day Robot <robot@bytheb.org>
hzhou8
added a commit
that referenced
this issue
Oct 21, 2020
The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > #4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > #5 0x51887b in main ic/ovn-ic.c:1674:17 > #6 0x7fd4ce7871a2 in __libc_start_main > #7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>
hzhou8
added a commit
that referenced
this issue
Oct 21, 2020
The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > #4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > #5 0x51887b in main ic/ovn-ic.c:1674:17 > #6 0x7fd4ce7871a2 in __libc_start_main > #7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>
hzhou8
added a commit
that referenced
this issue
Oct 21, 2020
The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > #4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > #5 0x51887b in main ic/ovn-ic.c:1674:17 > #6 0x7fd4ce7871a2 in __libc_start_main > #7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>
hzhou8
added a commit
that referenced
this issue
Oct 21, 2020
The 'nexthop' that passed to ic_route_hash() is not fully initialized in get_nexthop_from_lport_addresses(). 'nexthop' has type of 'struct v46_ip' which contains a union to share space for ipv4 and ipv6 address. If only ipv4 initialized where is a plenty of uninitialized space that goes to hash_bytes(nexthop, sizeof *nexthop, basis). Impact: there are two places where this function is called. 1. In add_to_routes_ad(), the nexthop is initialized in parse_route() before calling get_nexthop_from_lport_addresses(), luckily. 2. In add_network_to_routes_ad(), we are unlucky. When a directly connected network of a router is found to be advertised, if the route already existed in the global IC-SB, it may not be found due to the hash difference, and results in the existing route being deleted and the same one recreated, unnecessarily. This patch fixes the problem by initializing the struct to zero before setting the fields. From Ilya's report: > Report from MemorySanitizer: > > ==3074629==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x67177e in mhash_add__ ovs/./lib/hash.h:66:9 > #1 0x671668 in mhash_add ovs/./lib/hash.h:78:12 > #2 0x6701e9 in hash_bytes ovs/lib/hash.c:38:16 > #3 0x524b4a in add_network_to_routes_ad ic/ovn-ic.c:1095:5 > #4 0x51eea3 in route_run ic/ovn-ic.c:1424:21 > #5 0x51887b in main ic/ovn-ic.c:1674:17 > #6 0x7fd4ce7871a2 in __libc_start_main > #7 0x49c90d in _start (ic/ovn-ic+0x49c90d) > > Uninitialized value was created by an allocation of 'nexthop' in the > stack frame of function 'add_network_to_routes_ad' > #0 0x5245f0 in add_network_to_routes_ad ic/ovn-ic.c:1069 Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376160.html Fixes: 57b347c ("ovn-ic: Route advertisement.") Acked-by: Numan Siddique <numans@ovn.org> Signed-off-by: Han Zhou <hzhou@ovn.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 19, 2020
Result of 'normalize_v46_prefix()' should be freed and all dynamic
strings should be destroyed.
Direct leak of 156 byte(s) in 13 object(s) allocated from:
#0 0x53700f in malloc (northd/ovn-northd+0x53700f)
ovn-org#1 0x71b146 in xmalloc ovs/lib/util.c:138:15
ovn-org#2 0x71b39a in xvasprintf ovs/lib/util.c:202:9
ovn-org#3 0x71b753 in xasprintf ovs/lib/util.c:343:9
ovn-org#4 0x59bddc in add_ecmp_symmetric_reply_flows northd/ovn-northd.c:7985:18
ovn-org#5 0x59aab5 in build_ecmp_route_flow northd/ovn-northd.c:8102:13
ovn-org#6 0x592260 in build_static_route_flows_for_lrouter ovn-northd.c:10243:13
ovn-org#7 0x589267 in build_lswitch_and_lrouter_iterate_by_od ovn-northd.c:11241:5
ovn-org#8 0x5888ca in build_lswitch_and_lrouter_flows northd/ovn-northd.c:11313:9
ovn-org#9 0x5730a0 in build_lflows northd/ovn-northd.c:11401:5
ovn-org#10 0x56f992 in ovnnb_db_run northd/ovn-northd.c:12339:5
ovn-org#11 0x56e8a7 in ovn_db_run northd/ovn-northd.c:12932:5
ovn-org#12 0x56d6af in main northd/ovn-northd.c:13338:17
ovn-org#13 0x7f5371d041a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 4fdca65 ("Add ECMP symmetric replies.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
'child_port_list' is an array of pointers that should be freed too.
Direct leak of 30 byte(s) in 6 object(s) allocated from:
#0 0x501fff in malloc (/tests/ovstest+0x501fff)
ovn-org#1 0x6227e6 in xmalloc /lib/util.c:138:15
ovn-org#2 0x6228b8 in xmemdup0 /lib/util.c:168:15
ovn-org#3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30
ovn-org#4 0x814b6e in parse_action /lib/actions.c:3610:9
ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3637:14
ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9
ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5
ovn-org#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21
ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
ovn-org#12 0x537359 in main /tests/ovstest.c:133:9
ovn-org#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Manoj Sharma <manoj.sharma@nutanix.com>
Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
'dsts' should be freed in case of any error.
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x502378 in realloc (/tests/ovstest+0x502378)
ovn-org#1 0x622826 in xrealloc /lib/util.c:149:9
ovn-org#2 0x8194f4 in parse_select_action /lib/actions.c:1185:20
ovn-org#3 0x814f49 in parse_set_action /lib/actions.c:3499:13
ovn-org#4 0x814341 in parse_action /lib/actions.c:3554:9
ovn-org#5 0x8139ef in parse_actions /lib/actions.c:3643:14
ovn-org#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9
ovn-org#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5
ovn-org#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17
ovn-org#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
ovn-org#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
ovn-org#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
ovn-org#12 0x537359 in main /tests/ovstest.c:133:9
ovn-org#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Han Zhou <hzhou@ovn.org>
Fixes: 85b3544 ("ovn-controller: A new action "select".")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
'parse_ofp_meter_mod_str' allocates space for meter.bands that
should be freed.
Direct leak of 448 byte(s) in 7 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
ovn-org#1 0x7523a6 in xmalloc /lib/util.c:138:15
ovn-org#2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26
ovn-org#3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5
ovn-org#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19
ovn-org#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13
ovn-org#6 0x59aebb in main /controller/ovn-controller.c:2627:25
ovn-org#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Guoshuai Li <ligs@dtdream.com>
Fixes: c25094b ("ovn: OVN Support QoS meter")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
'smap_clear()' doesn't free allocated memory, but 'smap_clone()'
re-initializes hash map clearing internal pointers and leaking
this memory. 'smap_destroy()' should be used instead.
Also, all the records and array of datapaths should be freed on
destruction of a cache entry.
Direct leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7)
ovn-org#1 0x752364 in xcalloc /lib/util.c:121:31
ovn-org#2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25
ovn-org#3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
ovn-org#4 0x59b06c in main /controller/ovn-controller.c:2642:25
ovn-org#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Indirect leak of 26 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
ovn-org#1 0x7523d6 in xmalloc /lib/util.c:138:15
ovn-org#2 0x7524a8 in xmemdup0 /lib/util.c:168:15
ovn-org#3 0x73d8fc in smap_clone /lib/smap.c:314:45
ovn-org#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13
ovn-org#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
ovn-org#6 0x59b06c in main /controller/ovn-controller.c:2642:25
ovn-org#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 6b72068 ("ovn-controller: Add a new thread in pinctrl module to handle packet-ins.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
shash contains pointers to the data that should be freed.
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
ovn-org#1 0x752436 in xmalloc /lib/util.c:138:15
ovn-org#2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45
ovn-org#3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9
ovn-org#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5
ovn-org#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9
ovn-org#6 0x59adf4 in main /controller/ovn-controller.c
ovn-org#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: xu rong <xu.rong@zte.com.cn>
Fixes: 252e164 ("ovn-controller: pending_ct_zones should be destroyed")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 20, 2020
When a port binding of type "l3gateway" is claimed its remote peer
port_binding is also stored in local_datapath.peer_ports[].remote.
If the remote peer port_binding is deleted first (i.e., before the local
"l3gateway" one) then we need to remove the complete
local_datapath.peer_ports[] entry in order to avoid ending up using
dangling pointers to already freed port bindings.
Also, properly reset local_datapath->has_local_l3gateway in
remove_pb_from_local_datapath().
Ilya reported this issue found by AddressSanitizer during his testing:
==1816017==ERROR: AddressSanitizer: heap-use-after-free on address 0x6140000cb170 at pc 0x0000005ab574 bp 0x7fff68925a30 sp 0x7fff68925a28
READ of size 8 at 0x6140000cb170 thread T0
#0 0x5ab573 in put_replace_chassis_mac_flows git/ovn/controller/physical.c:550:9
ovn-org#1 0x5a65eb in consider_port_binding git/ovn/controller/physical.c:1168:13
ovn-org#2 0x5a8764 in physical_run git/ovn/controller/physical.c:1607:9
ovn-org#3 0x5a0064 in flow_output_physical_flow_changes_handler git/ovn/controller/ovn-controller.c:2127:9
ovn-org#4 0x5db423 in engine_compute git/ovn/lib/inc-proc-eng.c:306:18
ovn-org#5 0x5dae1f in engine_run_node git/ovn/lib/inc-proc-eng.c:352:14
ovn-org#6 0x5dac74 in engine_run git/ovn/lib/inc-proc-eng.c:377:9
ovn-org#7 0x59ad64 in main git/ovn/controller/ovn-controller.c
ovn-org#8 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
ovn-org#9 0x480b2d in _start (git/ovn/controller/ovn-controller+0x480b2d)
0x6140000cb170 is located 304 bytes inside of 408-byte region [0x6140000cb040,0x6140000cb1d8)
freed by thread T0 here:
#0 0x520d07 in free (git/ovn/controller/ovn-controller+0x520d07)
ovn-org#1 0x712de7 in ovsdb_idl_db_track_clear git/ovs/lib/ovsdb-idl.c:1984:21
ovn-org#2 0x59b5cd in main git/ovn/controller/ovn-controller.c:2762:9
ovn-org#3 0x7f39fa6491a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Reported-by: Ilya Maximets <i.maximets@ovn.org>
Fixes: 354bdba ("ovn-controller: I-P for SB port binding and OVS interface in runtime_data.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'child_port_list' is an array of pointers that should be freed too.
Direct leak of 30 byte(s) in 6 object(s) allocated from:
#0 0x501fff in malloc (/tests/ovstest+0x501fff)
#1 0x6227e6 in xmalloc /lib/util.c:138:15
#2 0x6228b8 in xmemdup0 /lib/util.c:168:15
#3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30
#4 0x814b6e in parse_action /lib/actions.c:3610:9
#5 0x8139ef in parse_actions /lib/actions.c:3637:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5
#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Manoj Sharma <manoj.sharma@nutanix.com>
Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'dsts' should be freed in case of any error.
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x502378 in realloc (/tests/ovstest+0x502378)
#1 0x622826 in xrealloc /lib/util.c:149:9
#2 0x8194f4 in parse_select_action /lib/actions.c:1185:20
#3 0x814f49 in parse_set_action /lib/actions.c:3499:13
#4 0x814341 in parse_action /lib/actions.c:3554:9
#5 0x8139ef in parse_actions /lib/actions.c:3643:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5
#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Han Zhou <hzhou@ovn.org>
Fixes: 85b3544 ("ovn-controller: A new action "select".")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'parse_ofp_meter_mod_str' allocates space for meter.bands that
should be freed.
Direct leak of 448 byte(s) in 7 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523a6 in xmalloc /lib/util.c:138:15
#2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26
#3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5
#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19
#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13
#6 0x59aebb in main /controller/ovn-controller.c:2627:25
#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Guoshuai Li <ligs@dtdream.com>
Fixes: c25094b ("ovn: OVN Support QoS meter")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'smap_clear()' doesn't free allocated memory, but 'smap_clone()'
re-initializes hash map clearing internal pointers and leaking
this memory. 'smap_destroy()' should be used instead.
Also, all the records and array of datapaths should be freed on
destruction of a cache entry.
Direct leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7)
#1 0x752364 in xcalloc /lib/util.c:121:31
#2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25
#3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#4 0x59b06c in main /controller/ovn-controller.c:2642:25
#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Indirect leak of 26 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523d6 in xmalloc /lib/util.c:138:15
#2 0x7524a8 in xmemdup0 /lib/util.c:168:15
#3 0x73d8fc in smap_clone /lib/smap.c:314:45
#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13
#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#6 0x59b06c in main /controller/ovn-controller.c:2642:25
#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 6b72068 ("ovn-controller: Add a new thread in pinctrl module to handle packet-ins.")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
shash contains pointers to the data that should be freed.
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x752436 in xmalloc /lib/util.c:138:15
#2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45
#3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9
#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5
#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9
#6 0x59adf4 in main /controller/ovn-controller.c
#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: xu rong <xu.rong@zte.com.cn>
Fixes: 252e164 ("ovn-controller: pending_ct_zones should be destroyed")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'child_port_list' is an array of pointers that should be freed too.
Direct leak of 30 byte(s) in 6 object(s) allocated from:
#0 0x501fff in malloc (/tests/ovstest+0x501fff)
#1 0x6227e6 in xmalloc /lib/util.c:138:15
#2 0x6228b8 in xmemdup0 /lib/util.c:168:15
#3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30
#4 0x814b6e in parse_action /lib/actions.c:3610:9
#5 0x8139ef in parse_actions /lib/actions.c:3637:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5
#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Manoj Sharma <manoj.sharma@nutanix.com>
Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'dsts' should be freed in case of any error.
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x502378 in realloc (/tests/ovstest+0x502378)
#1 0x622826 in xrealloc /lib/util.c:149:9
#2 0x8194f4 in parse_select_action /lib/actions.c:1185:20
#3 0x814f49 in parse_set_action /lib/actions.c:3499:13
#4 0x814341 in parse_action /lib/actions.c:3554:9
#5 0x8139ef in parse_actions /lib/actions.c:3643:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5
#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Han Zhou <hzhou@ovn.org>
Fixes: 85b3544 ("ovn-controller: A new action "select".")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'parse_ofp_meter_mod_str' allocates space for meter.bands that
should be freed.
Direct leak of 448 byte(s) in 7 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523a6 in xmalloc /lib/util.c:138:15
#2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26
#3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5
#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19
#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13
#6 0x59aebb in main /controller/ovn-controller.c:2627:25
#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Guoshuai Li <ligs@dtdream.com>
Fixes: c25094b ("ovn: OVN Support QoS meter")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'smap_clear()' doesn't free allocated memory, but 'smap_clone()'
re-initializes hash map clearing internal pointers and leaking
this memory. 'smap_destroy()' should be used instead.
Also, all the records and array of datapaths should be freed on
destruction of a cache entry.
Direct leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7)
#1 0x752364 in xcalloc /lib/util.c:121:31
#2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25
#3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#4 0x59b06c in main /controller/ovn-controller.c:2642:25
#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Indirect leak of 26 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523d6 in xmalloc /lib/util.c:138:15
#2 0x7524a8 in xmemdup0 /lib/util.c:168:15
#3 0x73d8fc in smap_clone /lib/smap.c:314:45
#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13
#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#6 0x59b06c in main /controller/ovn-controller.c:2642:25
#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 6b72068 ("ovn-controller: Add a new thread in pinctrl module to handle packet-ins.")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
shash contains pointers to the data that should be freed.
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x752436 in xmalloc /lib/util.c:138:15
#2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45
#3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9
#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5
#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9
#6 0x59adf4 in main /controller/ovn-controller.c
#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: xu rong <xu.rong@zte.com.cn>
Fixes: 252e164 ("ovn-controller: pending_ct_zones should be destroyed")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this issue
Nov 22, 2020
'child_port_list' is an array of pointers that should be freed too.
Direct leak of 30 byte(s) in 6 object(s) allocated from:
#0 0x501fff in malloc (/tests/ovstest+0x501fff)
#1 0x6227e6 in xmalloc /lib/util.c:138:15
#2 0x6228b8 in xmemdup0 /lib/util.c:168:15
#3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30
#4 0x814b6e in parse_action /lib/actions.c:3610:9
#5 0x8139ef in parse_actions /lib/actions.c:3637:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5
#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Manoj Sharma <manoj.sharma@nutanix.com>
Fixes: edb2400 ("Forwarding group to load balance l2 traffic with liveness detection")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
(cherry-picked from master commit 9443464)
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Apr 15, 2022
Avoid the following crash in ovn-trace due to a reject action infinite
loop:
AddressSanitizer:DEADLYSIGNAL
==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0)
#0 0x415081 in trace_actions utilities/ovn-trace.c:2617
ovn-org#1 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#2 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
ovn-org#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640
ovn-org#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#6 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#7 0x41788d in execute_next utilities/ovn-trace.c:2307
ovn-org#8 0x41788d in trace_actions utilities/ovn-trace.c:2644
ovn-org#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
ovn-org#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
ovn-org#11 0x419671 in execute_reject utilities/ovn-trace.c:2049
ovn-org#12 0x419671 in trace_actions utilities/ovn-trace.c:2860
ovn-org#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#14 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
ovn-org#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640
ovn-org#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#18 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#19 0x41788d in execute_next utilities/ovn-trace.c:2307
ovn-org#20 0x41788d in trace_actions utilities/ovn-trace.c:2644
ovn-org#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
ovn-org#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
ovn-org#23 0x419671 in execute_reject utilities/ovn-trace.c:2049
ovn-org#24 0x419671 in trace_actions utilities/ovn-trace.c:2860
ovn-org#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#26 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
ovn-org#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640
ovn-org#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#30 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#31 0x41788d in execute_next utilities/ovn-trace.c:2307
ovn-org#32 0x41788d in trace_actions utilities/ovn-trace.c:2644
ovn-org#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
ovn-org#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
ovn-org#35 0x419671 in execute_reject utilities/ovn-trace.c:2049
ovn-org#36 0x419671 in trace_actions utilities/ovn-trace.c:2860
ovn-org#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#38 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
ovn-org#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640
ovn-org#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622
ovn-org#42 0x41d878 in trace__ utilities/ovn-trace.c:3007
ovn-org#43 0x41788d in execute_next utilities/ovn-trace.c:2307
....
The issue can be triggered with the following reproducer:
$ovn-nbctl ls-add sw
$ovn-nbctl lsp-add sw p1
$ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2"
$ovn-nbctl lsp-add sw p2
$ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3"
$ovn-nbctl pg-add pg1 p1 p2
$ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow
$ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject
$ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3'
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
putnopvut
pushed a commit
that referenced
this issue
May 10, 2022
Avoid the following crash in ovn-trace due to a reject action infinite
loop:
AddressSanitizer:DEADLYSIGNAL
==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0)
#0 0x415081 in trace_actions utilities/ovn-trace.c:2617
#1 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#2 0x41d878 in trace__ utilities/ovn-trace.c:3007
#3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#6 0x41d878 in trace__ utilities/ovn-trace.c:3007
#7 0x41788d in execute_next utilities/ovn-trace.c:2307
#8 0x41788d in trace_actions utilities/ovn-trace.c:2644
#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#11 0x419671 in execute_reject utilities/ovn-trace.c:2049
#12 0x419671 in trace_actions utilities/ovn-trace.c:2860
#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#14 0x41d878 in trace__ utilities/ovn-trace.c:3007
#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#18 0x41d878 in trace__ utilities/ovn-trace.c:3007
#19 0x41788d in execute_next utilities/ovn-trace.c:2307
#20 0x41788d in trace_actions utilities/ovn-trace.c:2644
#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#23 0x419671 in execute_reject utilities/ovn-trace.c:2049
#24 0x419671 in trace_actions utilities/ovn-trace.c:2860
#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#26 0x41d878 in trace__ utilities/ovn-trace.c:3007
#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#30 0x41d878 in trace__ utilities/ovn-trace.c:3007
#31 0x41788d in execute_next utilities/ovn-trace.c:2307
#32 0x41788d in trace_actions utilities/ovn-trace.c:2644
#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#35 0x419671 in execute_reject utilities/ovn-trace.c:2049
#36 0x419671 in trace_actions utilities/ovn-trace.c:2860
#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#38 0x41d878 in trace__ utilities/ovn-trace.c:3007
#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#42 0x41d878 in trace__ utilities/ovn-trace.c:3007
#43 0x41788d in execute_next utilities/ovn-trace.c:2307
....
The issue can be triggered with the following reproducer:
$ovn-nbctl ls-add sw
$ovn-nbctl lsp-add sw p1
$ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2"
$ovn-nbctl lsp-add sw p2
$ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3"
$ovn-nbctl pg-add pg1 p1 p2
$ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow
$ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject
$ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3'
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Acked-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Mark Michelson <mmichels@redhat.com>
putnopvut
pushed a commit
that referenced
this issue
May 10, 2022
Avoid the following crash in ovn-trace due to a reject action infinite
loop:
AddressSanitizer:DEADLYSIGNAL
==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0)
#0 0x415081 in trace_actions utilities/ovn-trace.c:2617
#1 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#2 0x41d878 in trace__ utilities/ovn-trace.c:3007
#3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#6 0x41d878 in trace__ utilities/ovn-trace.c:3007
#7 0x41788d in execute_next utilities/ovn-trace.c:2307
#8 0x41788d in trace_actions utilities/ovn-trace.c:2644
#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#11 0x419671 in execute_reject utilities/ovn-trace.c:2049
#12 0x419671 in trace_actions utilities/ovn-trace.c:2860
#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#14 0x41d878 in trace__ utilities/ovn-trace.c:3007
#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#18 0x41d878 in trace__ utilities/ovn-trace.c:3007
#19 0x41788d in execute_next utilities/ovn-trace.c:2307
#20 0x41788d in trace_actions utilities/ovn-trace.c:2644
#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#23 0x419671 in execute_reject utilities/ovn-trace.c:2049
#24 0x419671 in trace_actions utilities/ovn-trace.c:2860
#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#26 0x41d878 in trace__ utilities/ovn-trace.c:3007
#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#30 0x41d878 in trace__ utilities/ovn-trace.c:3007
#31 0x41788d in execute_next utilities/ovn-trace.c:2307
#32 0x41788d in trace_actions utilities/ovn-trace.c:2644
#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#35 0x419671 in execute_reject utilities/ovn-trace.c:2049
#36 0x419671 in trace_actions utilities/ovn-trace.c:2860
#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#38 0x41d878 in trace__ utilities/ovn-trace.c:3007
#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#42 0x41d878 in trace__ utilities/ovn-trace.c:3007
#43 0x41788d in execute_next utilities/ovn-trace.c:2307
....
The issue can be triggered with the following reproducer:
$ovn-nbctl ls-add sw
$ovn-nbctl lsp-add sw p1
$ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2"
$ovn-nbctl lsp-add sw p2
$ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3"
$ovn-nbctl pg-add pg1 p1 p2
$ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow
$ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject
$ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3'
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Acked-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Mark Michelson <mmichels@redhat.com>
putnopvut
pushed a commit
that referenced
this issue
May 10, 2022
Avoid the following crash in ovn-trace due to a reject action infinite
loop:
AddressSanitizer:DEADLYSIGNAL
==569410==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0a991bc4 (pc 0x000000415081 bp 0x7ffc0a993fa0 sp 0x7ffc0a991b30 T0)
#0 0x415081 in trace_actions utilities/ovn-trace.c:2617
#1 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#2 0x41d878 in trace__ utilities/ovn-trace.c:3007
#3 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#4 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#5 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#6 0x41d878 in trace__ utilities/ovn-trace.c:3007
#7 0x41788d in execute_next utilities/ovn-trace.c:2307
#8 0x41788d in trace_actions utilities/ovn-trace.c:2644
#9 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#10 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#11 0x419671 in execute_reject utilities/ovn-trace.c:2049
#12 0x419671 in trace_actions utilities/ovn-trace.c:2860
#13 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#14 0x41d878 in trace__ utilities/ovn-trace.c:3007
#15 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#16 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#17 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#18 0x41d878 in trace__ utilities/ovn-trace.c:3007
#19 0x41788d in execute_next utilities/ovn-trace.c:2307
#20 0x41788d in trace_actions utilities/ovn-trace.c:2644
#21 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#22 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#23 0x419671 in execute_reject utilities/ovn-trace.c:2049
#24 0x419671 in trace_actions utilities/ovn-trace.c:2860
#25 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#26 0x41d878 in trace__ utilities/ovn-trace.c:3007
#27 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#28 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#29 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#30 0x41d878 in trace__ utilities/ovn-trace.c:3007
#31 0x41788d in execute_next utilities/ovn-trace.c:2307
#32 0x41788d in trace_actions utilities/ovn-trace.c:2644
#33 0x41a7c0 in trace_actions utilities/ovn-trace.c:2622
#34 0x41a7c0 in execute_sctp4_abort utilities/ovn-trace.c:1985
#35 0x419671 in execute_reject utilities/ovn-trace.c:2049
#36 0x419671 in trace_actions utilities/ovn-trace.c:2860
#37 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#38 0x41d878 in trace__ utilities/ovn-trace.c:3007
#39 0x41e3a8 in execute_output utilities/ovn-trace.c:1700
#40 0x416fcf in trace_actions utilities/ovn-trace.c:2640
#41 0x41d878 in trace_actions utilities/ovn-trace.c:2622
#42 0x41d878 in trace__ utilities/ovn-trace.c:3007
#43 0x41788d in execute_next utilities/ovn-trace.c:2307
....
The issue can be triggered with the following reproducer:
$ovn-nbctl ls-add sw
$ovn-nbctl lsp-add sw p1
$ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2"
$ovn-nbctl lsp-add sw p2
$ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3"
$ovn-nbctl pg-add pg1 p1 p2
$ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst == 9000" allow
$ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject
$ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3'
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2074537
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Acked-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Mark Michelson <mmichels@redhat.com>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Aug 19, 2022
Fix the problem introduced by commit e52c245, reported by ASAN for test case: "options:activation-strategy for logical port" ==1480622==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61100000c7d0 at pc 0x0000004fbd91 bp 0x7ffec4244630 sp 0x7ffec4243de0 READ of size 168 at 0x61100000c7d0 thread T0 #0 0x4fbd90 in __interceptor_memcpy.part.0 (/home/hanzhou/src/ovn/_build_as/controller/ovn-controller+0x4fbd90) ovn-org#1 0x73457f in ofpbuf_put /home/hanzhou/src/ovs/_build/../lib/ofpbuf.c:431:5 ovn-org#2 0x73457f in ofpbuf_put /home/hanzhou/src/ovs/_build/../lib/ofpbuf.c:424:1 ovn-org#3 0x72ba29 in ofpprop_put /home/hanzhou/src/ovs/_build/../lib/ofp-prop.c:294:5 ovn-org#4 0x7046e7 in encode_CONTROLLER /home/hanzhou/src/ovs/_build/../lib/ofp-actions.c:914:13 ovn-org#5 0x7046e7 in encode_ofpact /home/hanzhou/src/ovs/_build/../lib/ofp-actions.c:8890:9 ovn-org#6 0x705878 in ofpacts_put_openflow_instructions /home/hanzhou/src/ovs/_build/../lib/ofp-actions.c:8943:17 ovn-org#7 0x716287 in ofputil_encode_flow_mod /home/hanzhou/src/ovs/_build/../lib/ofp-flow.c:426:9 ovn-org#8 0x5c5978 in encode_flow_mod /home/hanzhou/src/ovn/_build_as/../controller/ofctrl.c:1893:12 ovn-org#9 0x5c5978 in add_flow_mod /home/hanzhou/src/ovn/_build_as/../controller/ofctrl.c:1912:26 ovn-org#10 0x5c5978 in installed_flow_add /home/hanzhou/src/ovn/_build_as/../controller/ofctrl.c:2254:5 ovn-org#11 0x5bfd62 in update_installed_flows_by_track /home/hanzhou/src/ovn/_build_as/../controller/ofctrl.c:2484:17 ovn-org#12 0x5bc5b9 in ofctrl_put /home/hanzhou/src/ovn/_build_as/../controller/ofctrl.c:2715:13 ovn-org#13 0x600e97 in main /home/hanzhou/src/ovn/_build_as/../controller/ovn-controller.c:4186:25 ovn-org#14 0x7f7ae80ce1a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) ovn-org#15 0x49432d in _start (/home/hanzhou/src/ovn/_build_as/controller/ovn-controller+0x49432d) Fixes: e52c245 ("physical.c: Fix bug of wrong use in vm migration") Signed-off-by: Han Zhou <hzhou@ovn.org> Signed-off-by: 0-day Robot <robot@bytheb.org>
dceara
added a commit
to dceara/ovn
that referenced
this issue
Nov 2, 2022
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
ovn-org#1 0x621b8f in pinctrl_handle_bfd_msg /root/ovn/controller/pinctrl.c:7183:10
ovn-org#2 0x621b8f in process_packet_in /root/ovn/controller/pinctrl.c:3320:9
ovn-org#3 0x621b8f in pinctrl_recv /root/ovn/controller/pinctrl.c:3386:9
ovn-org#4 0x621b8f in pinctrl_handler /root/ovn/controller/pinctrl.c:3481:17
ovn-org#5 0xa2d89a in ovsthread_wrapper /root/ovn/ovs/lib/ovs-thread.c:422:12
ovn-org#6 0x7fcb598081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
ovn-org#7 0x7fcb58439dd2 in clone (/lib64/libc.so.6+0x39dd2)
Fixes: 1172035 ("controller: introduce BFD tx path in ovn-controller.")
Reported-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Nov 2, 2022
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
ovn-org#1 0x621b8f in pinctrl_handle_bfd_msg /root/ovn/controller/pinctrl.c:7183:10
ovn-org#2 0x621b8f in process_packet_in /root/ovn/controller/pinctrl.c:3320:9
ovn-org#3 0x621b8f in pinctrl_recv /root/ovn/controller/pinctrl.c:3386:9
ovn-org#4 0x621b8f in pinctrl_handler /root/ovn/controller/pinctrl.c:3481:17
ovn-org#5 0xa2d89a in ovsthread_wrapper /root/ovn/ovs/lib/ovs-thread.c:422:12
ovn-org#6 0x7fcb598081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
ovn-org#7 0x7fcb58439dd2 in clone (/lib64/libc.so.6+0x39dd2)
Fixes: 1172035 ("controller: introduce BFD tx path in ovn-controller.")
Reported-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
dceara
added a commit
to dceara/ovn
that referenced
this issue
Nov 17, 2022
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
ovn-org#1 0x621b8f in pinctrl_handle_bfd_msg /root/ovn/controller/pinctrl.c:7183:10
ovn-org#2 0x621b8f in process_packet_in /root/ovn/controller/pinctrl.c:3320:9
ovn-org#3 0x621b8f in pinctrl_recv /root/ovn/controller/pinctrl.c:3386:9
ovn-org#4 0x621b8f in pinctrl_handler /root/ovn/controller/pinctrl.c:3481:17
ovn-org#5 0xa2d89a in ovsthread_wrapper /root/ovn/ovs/lib/ovs-thread.c:422:12
ovn-org#6 0x7fcb598081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
ovn-org#7 0x7fcb58439dd2 in clone (/lib64/libc.so.6+0x39dd2)
Fixes: 1172035 ("controller: introduce BFD tx path in ovn-controller.")
Reported-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
almusil
added a commit
to almusil/ovn
that referenced
this issue
Feb 22, 2023
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
#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Feb 22, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
almusil
added a commit
to almusil/ovn
that referenced
this issue
Feb 22, 2023
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
#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
---
v2: Address comments from Simon:
- Rearrange the cleanup according to suggestion.
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Feb 22, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
(cherry picked from commit 577a797)
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
(cherry picked from commit 577a797)
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
(cherry picked from commit 577a797)
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
(cherry picked from commit 577a797)
dceara
pushed a commit
to dceara/ovn
that referenced
this issue
Mar 2, 2023
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
ovn-org#1 0xa530a5 in xrealloc__ /workspace/ovn/ovs/lib/util.c:147:9
ovn-org#2 0xa530a5 in xrealloc /workspace/ovn/ovs/lib/util.c:179:12
ovn-org#3 0xa530a5 in x2nrealloc /workspace/ovn/ovs/lib/util.c:239:12
ovn-org#4 0xa2ee57 in svec_expand /workspace/ovn/ovs/lib/svec.c:92:23
ovn-org#5 0xa2ef6e in svec_terminate /workspace/ovn/ovs/lib/svec.c:116:5
ovn-org#6 0x82c117 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:98:5
ovn-org#7 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c041 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:91:5
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#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)
ovn-org#1 0xa52d4c in xmalloc__ /workspace/ovn/ovs/lib/util.c:137:15
ovn-org#2 0xa52d4c in xmalloc /workspace/ovn/ovs/lib/util.c:172:12
ovn-org#3 0xa52d4c in xmemdup0 /workspace/ovn/ovs/lib/util.c:193:15
ovn-org#4 0xa2e580 in svec_add /workspace/ovn/ovs/lib/svec.c:71:27
ovn-org#5 0x82c0b6 in ovs_cmdl_env_parse_all /workspace/ovn/ovs/lib/command-line.c:96:9
ovn-org#6 0x5ad70d in ovn_dbctl_main /workspace/ovn/utilities/ovn-dbctl.c:132:20
ovn-org#7 0x5b58c7 in main /workspace/ovn/utilities/ovn-nbctl.c:7943:12
Signed-off-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
(cherry picked from commit 577a797)
hzhou8
added a commit
to hzhou8/ovn
that referenced
this issue
Jun 29, 2023
…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)
#1 0x773f4e in xcalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:121:31
#2 0x773f4e in xzalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:131:12
#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
ovn-org#5 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5
ovn-org#6 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17
ovn-org#7 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14
ovn-org#8 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9
ovn-org#9 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9
ovn-org#10 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33
ovn-org#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)
#1 0x773c7d in xrealloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:147:9
#2 0x773c7d in xrealloc /home/hanzhou/src/ovs/_build/../lib/util.c:179:12
#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
ovn-org#5 0x5c8d90 in parse_lsp_addrs /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2468:21
ovn-org#6 0x5b2ebf in join_logical_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2594:13
ovn-org#7 0x5b2ebf in build_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:4711:5
ovn-org#8 0x5b2ebf in ovnnb_db_run /home/hanzhou/src/ovn/_build_as/../northd/northd.c:17376:5
ovn-org#9 0x60106c in en_northd_run /home/hanzhou/src/ovn/_build_as/../northd/en-northd.c:137:5
ovn-org#10 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5
ovn-org#11 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17
ovn-org#12 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14
ovn-org#13 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9
ovn-org#14 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9
ovn-org#15 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33
ovn-org#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 <dceara@redhat.com>
Signed-off-by: Han Zhou <hzhou@ovn.org>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Jun 29, 2023
…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)
ovn-org#1 0x773f4e in xcalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:121:31
ovn-org#2 0x773f4e in xzalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:131:12
ovn-org#3 0x773f4e in xzalloc /home/hanzhou/src/ovs/_build/../lib/util.c:165:12
ovn-org#4 0x60106c in en_northd_run /home/hanzhou/src/ovn/_build_as/../northd/en-northd.c:137:5
ovn-org#5 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5
ovn-org#6 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17
ovn-org#7 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14
ovn-org#8 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9
ovn-org#9 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9
ovn-org#10 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33
ovn-org#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)
ovn-org#1 0x773c7d in xrealloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:147:9
ovn-org#2 0x773c7d in xrealloc /home/hanzhou/src/ovs/_build/../lib/util.c:179:12
ovn-org#3 0x614bd4 in extract_addresses /home/hanzhou/src/ovn/_build_as/../lib/ovn-util.c:228:12
ovn-org#4 0x614bd4 in extract_lsp_addresses /home/hanzhou/src/ovn/_build_as/../lib/ovn-util.c:243:20
ovn-org#5 0x5c8d90 in parse_lsp_addrs /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2468:21
ovn-org#6 0x5b2ebf in join_logical_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:2594:13
ovn-org#7 0x5b2ebf in build_ports /home/hanzhou/src/ovn/_build_as/../northd/northd.c:4711:5
ovn-org#8 0x5b2ebf in ovnnb_db_run /home/hanzhou/src/ovn/_build_as/../northd/northd.c:17376:5
ovn-org#9 0x60106c in en_northd_run /home/hanzhou/src/ovn/_build_as/../northd/en-northd.c:137:5
ovn-org#10 0x61c6a8 in engine_recompute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:415:5
ovn-org#11 0x61bee0 in engine_compute /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:454:17
ovn-org#12 0x61bee0 in engine_run_node /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:503:14
ovn-org#13 0x61bee0 in engine_run /home/hanzhou/src/ovn/_build_as/../lib/inc-proc-eng.c:528:9
ovn-org#14 0x605e23 in inc_proc_northd_run /home/hanzhou/src/ovn/_build_as/../northd/inc-proc-northd.c:317:9
ovn-org#15 0x5fe43b in main /home/hanzhou/src/ovn/_build_as/../northd/ovn-northd.c:934:33
ovn-org#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 <dceara@redhat.com>
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: 0-day Robot <robot@bytheb.org>
hzhou8
added a commit
that referenced
this issue
Jun 30, 2023
…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)
#1 0x773f4e in xcalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:121:31
#2 0x773f4e in xzalloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:131:12
#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
#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)
#1 0x773c7d in xrealloc__ /home/hanzhou/src/ovs/_build/../lib/util.c:147:9
#2 0x773c7d in xrealloc /home/hanzhou/src/ovs/_build/../lib/util.c:179:12
#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
#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
#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 <dceara@redhat.com>
Signed-off-by: Han Zhou <hzhou@ovn.org>
Acked-by: Dumitru Ceara <dceara@redhat.com>
ovsrobot
pushed a commit
to ovsrobot/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ales Musil <amusil@redhat.com>
Acked-by: Ales Musil <amusil@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
to dceara/ovn
that referenced
this issue
Jul 14, 2023
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)
ovn-org#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
ovn-org#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
ovn-org#3 0x55e5b642cebc in pinctrl_parse_dhcpv6_reply /workspace/ovn-tmp/controller/pinctrl.c:997:20
ovn-org#4 0x55e5b642cebc in pinctrl_handle_dhcp6_server /workspace/ovn-tmp/controller/pinctrl.c:1040:9
ovn-org#5 0x55e5b642cebc in process_packet_in /workspace/ovn-tmp/controller/pinctrl.c:3210:9
ovn-org#6 0x55e5b642cebc in pinctrl_recv /workspace/ovn-tmp/controller/pinctrl.c:3290:9
ovn-org#7 0x55e5b642cebc in pinctrl_handler /workspace/ovn-tmp/controller/pinctrl.c:3385:17
ovn-org#8 0x55e5b66ef664 in ovsthread_wrapper /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
ovn-org#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
(cherry picked from commit 602d8ba)
dceara
added a commit
that referenced
this issue
Jul 14, 2023
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)
#1 0x55e5b671878d in xmalloc__ /workspace/ovn-tmp/ovs/lib/util.c:140:15
#2 0x55e5b671878d in xmalloc /workspace/ovn-tmp/ovs/lib/util.c:175:12
#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
#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 <amusil@redhat.com>
Co-authored-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the following Link is no longer valid:
https://github.com/ovn-org/ovn/blob/master/Documentation/tutorials/ovs-advanced.rst
The text was updated successfully, but these errors were encountered: