Donald Sharp [Fri, 25 Aug 2023 14:43:56 +0000 (10:43 -0400)]
bgpd: Prevent use after free
When bgp_stop finishes and it deletes the peer it is sending
back a return code stating that the peer was deleted, but
the code was operating like it was not deleted and continued
to access the data structure. Fix.
Donald Sharp [Fri, 25 Aug 2023 14:28:02 +0000 (10:28 -0400)]
bgpd: bgp_event_update switch to a switch
The return code from a event handling perspective
is an enum. Let's intentionally make it a switch
so that all cases are ensured to be covered now
and in the future.
Donatas Abraitis [Thu, 24 Aug 2023 15:06:17 +0000 (18:06 +0300)]
staticd: Accept full blackhole typed keywords for ip_route_cmd
Before this patch we allow entering next-hop interface address as any string.
Like, we can type: `ip route 10.10.10.10/32 bla`, but this will create a blackhole
route instead of using an interface `bla`.
The same is with reject.
After the patch:
```
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 bla'
ERROR: SET_CONFIG request failed, Error: nexthop interface name must be (reject, blackhole)
$ ip link show dev bla
472: bla: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether fa:45:bd:f1:f8:f0 brd ff:ff:ff:ff:ff:ff
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 blac'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 blackhole
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 blac'
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 blackhole'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 blackhole
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 blackhole'
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 Null0'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 Null0
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 Null0'
$ vtysh -c 'sh run | include ip route'
$
```
乐倚 [Wed, 23 Aug 2023 08:42:33 +0000 (08:42 +0000)]
configure.ac: fix protobuf config
Bug description: frr_init load zebra_fpm.so error. Zebra can't
find function `zfpm_protobuf_encode_route` in symbol table.
Bug trigger condition ( CI have this set ):
./configure --enable-protobuf=no --enable-fpm=yes
/usr/lib/frr/zebra -M fpm
Cause: Macro `HAVE_PROTOBUF` and compile condition variable
`HAVE_PROTOBUF` in `configure.ac ` is not consistent. When
configure `disable-protobuf`, compile condition variable
`HAVE_PROTOBUF` is 0, but the macro is 1. It leads to zebra
load protobuf module, but protobuf module is not linked.
Fix: add a same condition statement to the macro define.
Keelan10 [Wed, 23 Aug 2023 05:23:48 +0000 (09:23 +0400)]
ospf6d: Free Newly Created LSA when Non-Self-Originated Grace LSA is Discarded
The newly created LSA `new` is now properly freed to prevent memory leaks when
a non-self-originated Grace LSA which is not in LSDB is received.
The ASan leak log for reference:
```
Direct leak of 400 byte(s) in 2 object(s) allocated from:
#0 0x7f70e984bd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f70e92481c5 in qcalloc lib/memory.c:105
#2 0x55b35068c975 in ospf6_lsa_alloc ospf6d/ospf6_lsa.c:710
#3 0x55b35068c9f9 in ospf6_lsa_create ospf6d/ospf6_lsa.c:725
#4 0x55b35065ab2c in ospf6_receive_lsa ospf6d/ospf6_flood.c:912
#5 0x55b3506a1413 in ospf6_lsupdate_recv ospf6d/ospf6_message.c:1621
#6 0x55b3506a1413 in ospf6_read_helper ospf6d/ospf6_message.c:1896
#7 0x55b3506a1413 in ospf6_receive ospf6d/ospf6_message.c:1925
#8 0x7f70e92e6ccb in event_call lib/event.c:1979
#9 0x7f70e922b488 in frr_run lib/libfrr.c:1213
#10 0x55b35064345e in main ospf6d/ospf6_main.c:250
#11 0x7f70e8843c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 72 byte(s) in 2 object(s) allocated from:
#0 0x7f70e984bb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f70e9247ee5 in qmalloc lib/memory.c:100
#2 0x55b35068c987 in ospf6_lsa_alloc ospf6d/ospf6_lsa.c:711
#3 0x55b35068c9f9 in ospf6_lsa_create ospf6d/ospf6_lsa.c:725
#4 0x55b35065ab2c in ospf6_receive_lsa ospf6d/ospf6_flood.c:912
#5 0x55b3506a1413 in ospf6_lsupdate_recv ospf6d/ospf6_message.c:1621
#6 0x55b3506a1413 in ospf6_read_helper ospf6d/ospf6_message.c:1896
#7 0x55b3506a1413 in ospf6_receive ospf6d/ospf6_message.c:1925
#8 0x7f70e92e6ccb in event_call lib/event.c:1979
#9 0x7f70e922b488 in frr_run lib/libfrr.c:1213
#10 0x55b35064345e in main ospf6d/ospf6_main.c:250
#11 0x7f70e8843c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 472 byte(s) leaked in 4 allocation(s).
```
Keelan10 [Tue, 22 Aug 2023 13:19:51 +0000 (17:19 +0400)]
lib: Fix memory leaks in LS Update Functions
Previously when updating vertices, edges and subnets, when no update was required
due to existing value matching the new one, memory associated with the new object
was not being freed leading to memory leaks. This commit fixes memory leak by
freeing memory associated with new object when update is unnecessary.
The ASan leak log for reference:
```
Direct leak of 312 byte(s) in 3 object(s) allocated from:
#0 0x7faf3afbfa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7faf3ab5dbcf in qcalloc ../lib/memory.c:105
#2 0x7faf3ab42e00 in ls_parse_prefix ../lib/link_state.c:1323
#3 0x7faf3ab43c87 in ls_parse_msg ../lib/link_state.c:1373
#4 0x7faf3ab476a5 in ls_stream2ted ../lib/link_state.c:1885
#5 0x564e045046aa in sharp_opaque_handler ../sharpd/sharp_zebra.c:792
#6 0x7faf3aca35a9 in zclient_read ../lib/zclient.c:4410
#7 0x7faf3ac47474 in event_call ../lib/event.c:1979
#8 0x7faf3ab318b4 in frr_run ../lib/libfrr.c:1213
#9 0x564e044fdc6f in main ../sharpd/sharp_main.c:177
#10 0x7faf3a6f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 312 byte(s) leaked in 3 allocation(s).
```
Donald Sharp [Mon, 21 Aug 2023 19:37:32 +0000 (15:37 -0400)]
zebra: Prevent protodown_rc from going Bzonkas
The code that handles the protodown_rc setting for
VRRP interfaces in zebra is sending a interface
to be set into a protodown state *before* the
interface has been learned by the kernel. Resulting
in crashes when the data plane sends the ctx back
to us saying hey man you are uncool.
Additionally change the protodown code to refuse
to send any protodown_rc codes *until* the interface
has actually been learned about from the kernel.
Ticket: 3582375 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Keelan10 [Sat, 19 Aug 2023 21:16:48 +0000 (01:16 +0400)]
lib: Clear Computed Path Pointer to Destination on Clean
This commit ensures proper cleanup by clearing the `algo->pdst` pointer if it points to a path that is being deleted.
It addresses memory leaks by freeing memory held by `algo->pdst` that might not have been released during the cleanup of processed paths.
The ASan leak log for reference:
```
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffc9d1a54 in cpath_new ../lib/cspf.c:44
#3 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#4 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#5 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#6 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#7 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#8 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#9 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#10 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#11 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#12 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#13 0x7fbffcb51324 in event_call ../lib/event.c:1979
#14 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#15 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#16 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffca3c108 in list_new ../lib/linklist.c:49
#3 0x7fbffc9d1acc in cpath_new ../lib/cspf.c:47
#4 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#5 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#6 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#7 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#8 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#9 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#10 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#11 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#12 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#13 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#14 0x7fbffcb51324 in event_call ../lib/event.c:1979
#15 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#16 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#17 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Donald Sharp [Sun, 20 Aug 2023 22:43:48 +0000 (18:43 -0400)]
tests: static_simple gives up after 3 seconds
Under heavy system load we can see that the static_simple
test is giving up too early in this micronet run:
8-17 15:00:27,105 DEBUG: topo: Waiting for [0.1]s as initial delay
2023-08-17 15:00:27,206 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:28,209 DEBUG: r1:
stdout: 101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:28,209 DEBUG: topo: checking kernel routing table:
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:28,210 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:28,210 DEBUG: topo: Sleeping 2s until next retry with 3.0 retry time left
2023-08-17 15:00:30,211 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:31,703 DEBUG: r1:
stdout: 101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:31,703 DEBUG: topo: checking kernel routing table:
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:31,704 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:31,704 INFO: topo: Retry timeout of 3s reached
2023-08-17 15:00:31,704 INFO: topo: Spawn collection of support bundle for r1
2023-08-17 15:00:31,704 DEBUG: r1: cmd_status("/bin/bash -c 'mkdir -p /tmp/topotests/static_simple.test_static_simple/r1/support_bundles/test_static_cli'")
2023-08-17 15:00:31,710 DEBUG: r1: popen("/usr/lib/frr/generate_support_bundle.py --log-dir=/tmp/topotests/static_simple.test_static_simple/r1/support_bundles/test_static_cli")
2023-08-17 15:00:31,711 DEBUG: topo: Waiting on support bundle for r1
2023-08-17 15:00:31,751 DEBUG: topo: RETRY DIAG: [failure] Sleeping 2s until next retry with 2.2 retry time left - too see if timeout was too short
2023-08-17 15:00:33,751 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:35,137 DEBUG: r1:
stdout: 10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20...
2023-08-17 15:00:35,137 DEBUG: topo: checking kernel routing table:
10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:35,137 DEBUG: topo: Function returned None
2023-08-17 15:00:35,138 WARN: topo: RETRY DIAGNOSTIC: SUCCEED after FAILED with requested timeout of 3.0s; however, succeeded in 8.0s, investigate timeout timing
2023-08-17 15:00:35,138 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:35,138 DEBUG: topo: RETRY DIAG: [failure] Sleeping 2s until next retry with 0.2 retry time left - too see if timeout was too short
2023-08-17 15:00:37,139 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:37,247 DEBUG: r1:
stdout: 10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20...
Of course it works in the extra couple of times it tries but the test still fails.
Donatas Abraitis [Fri, 18 Aug 2023 08:28:03 +0000 (11:28 +0300)]
bgpd: Make sure we have enough data to read two bytes when validating AIGP
Found when fuzzing:
```
==3470861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffff77801ef7 at pc 0xaaaaba7b3dbc bp 0xffffcff0e760 sp 0xffffcff0df50
READ of size 2 at 0xffff77801ef7 thread T0
0 0xaaaaba7b3db8 in __asan_memcpy (/home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgpd+0x363db8) (BuildId: cc710a2356e31c7f4e4a17595b54de82145a6e21)
1 0xaaaaba81a8ac in ptr_get_be16 /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/./lib/stream.h:399:2
2 0xaaaaba819f2c in bgp_attr_aigp_valid /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:504:3
3 0xaaaaba808c20 in bgp_attr_aigp /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3275:7
4 0xaaaaba7ff4e0 in bgp_attr_parse /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3678:10
```
Keelan10 [Thu, 17 Aug 2023 19:54:33 +0000 (23:54 +0400)]
pbrd: Correct Handling of Sequence Deletion
This commit ensures that sequence data
and associated structures are correctly deleted to prevent memory leaks
The ASan leak log for reference:
```
Direct leak of 432 byte(s) in 1 object(s) allocated from:
#0 0x7f911ebaba37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f911e749a4e in qcalloc ../lib/memory.c:105
#2 0x564fd444b2d3 in pbrms_get ../pbrd/pbr_map.c:527
#3 0x564fd443a82d in pbr_map ../pbrd/pbr_vty.c:90
#4 0x7f911e691d61 in cmd_execute_command_real ../lib/command.c:993
#5 0x7f911e6920ee in cmd_execute_command ../lib/command.c:1052
#6 0x7f911e692dc0 in cmd_execute ../lib/command.c:1218
#7 0x7f911e843197 in vty_command ../lib/vty.c:591
#8 0x7f911e84807c in vty_execute ../lib/vty.c:1354
#9 0x7f911e84e47a in vtysh_read ../lib/vty.c:2362
#10 0x7f911e8332f4 in event_call ../lib/event.c:1979
#11 0x7f911e71d828 in frr_run ../lib/libfrr.c:1213
#12 0x564fd4425795 in main ../pbrd/pbr_main.c:168
#13 0x7f911e2e1d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Keelan10 [Sat, 19 Aug 2023 14:38:14 +0000 (18:38 +0400)]
ospfd: Delete `q_space->vertex_list` on No Backup Path
In scenarios where no backup paths are available, ensure proper
memory management by deleting `q_space->vertex_list`. This prevents
memory leaks.
The ASan leak log for reference:
```
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fcf8c70aa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fcf8c2a8a45 in qcalloc ../lib/memory.c:105
#2 0x7fcf8c27d0cc in list_new ../lib/linklist.c:49
#3 0x55d6e8385e35 in ospf_spf_init ../ospfd/ospf_spf.c:540
#4 0x55d6e838c30d in ospf_spf_calculate ../ospfd/ospf_spf.c:1736
#5 0x55d6e83933cf in ospf_ti_lfa_generate_q_spaces ../ospfd/ospf_ti_lfa.c:673
#6 0x55d6e8394214 in ospf_ti_lfa_generate_p_space ../ospfd/ospf_ti_lfa.c:812
#7 0x55d6e8394c63 in ospf_ti_lfa_generate_p_spaces ../ospfd/ospf_ti_lfa.c:923
#8 0x55d6e8396390 in ospf_ti_lfa_compute ../ospfd/ospf_ti_lfa.c:1101
#9 0x55d6e838ca48 in ospf_spf_calculate_area ../ospfd/ospf_spf.c:1811
#10 0x55d6e838cd73 in ospf_spf_calculate_areas ../ospfd/ospf_spf.c:1840
#11 0x55d6e838cfb0 in ospf_spf_calculate_schedule_worker ../ospfd/ospf_spf.c:1871
#12 0x7fcf8c3922e4 in event_call ../lib/event.c:1979
#13 0x7fcf8c27c828 in frr_run ../lib/libfrr.c:1213
#14 0x55d6e82eeb6d in main ../ospfd/ospf_main.c:249
#15 0x7fcf8bd59d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Keelan10 [Sat, 19 Aug 2023 10:00:17 +0000 (14:00 +0400)]
bgpd: Free memory in set_aspath_exclude_access_list
Properly free the dynamically allocated memory held by `str` after its use.
The change also maintains the return value of `nb_cli_apply_changes` by using `ret` variable.
The ASan leak log for reference:
```
Direct leak of 55 byte(s) in 2 object(s) allocated from:
#0 0x7f16f285f867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f16f23fda11 in qmalloc ../lib/memory.c:100
#2 0x7f16f23a01a0 in frrstr_join ../lib/frrstr.c:89
#3 0x7f16f23418c7 in argv_concat ../lib/command.c:183
#4 0x55aba24731f2 in set_aspath_exclude_access_list_magic ../bgpd/bgp_routemap.c:6327
#5 0x55aba2455cf4 in set_aspath_exclude_access_list bgpd/bgp_routemap_clippy.c:836
#6 0x7f16f2345d61 in cmd_execute_command_real ../lib/command.c:993
#7 0x7f16f23460ee in cmd_execute_command ../lib/command.c:1052
#8 0x7f16f2346dc0 in cmd_execute ../lib/command.c:1218
#9 0x7f16f24f7197 in vty_command ../lib/vty.c:591
#10 0x7f16f24fc07c in vty_execute ../lib/vty.c:1354
#11 0x7f16f250247a in vtysh_read ../lib/vty.c:2362
#12 0x7f16f24e72f4 in event_call ../lib/event.c:1979
#13 0x7f16f23d1828 in frr_run ../lib/libfrr.c:1213
#14 0x55aba2269e52 in main ../bgpd/bgp_main.c:510
#15 0x7f16f1dbfd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Donald Sharp [Tue, 10 Aug 2021 03:43:46 +0000 (23:43 -0400)]
bgpd: Convert `struct peer_connection` to dynamically allocated
As part of the conversion to a `struct peer_connection` it will
be desirable to have 2 pointers one for when we open a connection
and one for when we receive a connection. Start this actual
conversion over to this in `struct peer`. If this sounds confusing
take a look at the bgp state machine for connections and how
it resolves the processing of this router opening -vs- this
router receiving an open. At some point in time the state
machine decides that we are keeping one of the two connections.
Future commits will allow us to untangle the peer/doppelganger
duality with this abstraction.
Donald Sharp [Fri, 30 Apr 2021 18:55:40 +0000 (14:55 -0400)]
bgpd: Start abstraction of `struct peer_connection`
BGP tracks connections based upon the peer. But the problem
with this is that the doppelganger structure for it is being
created. This has introduced a bunch of fragileness in that
the peer exists independently of the connections to it.
The whole point of the doppelganger structure was to allow
BGP to both accept and initiate tcp connections and then
when we get one to a `good` state we collapse into the
appropriate one. The problem with this is that having
2 peer structures for this creates a situation where
we have to make sure we are configing the `right` one
and also make sure that we collapse the two independent
peer structures into 1 acting peer. This makes no sense
let's abstract out the peer into having 2 connection
one for incoming connections and one for outgoing connections
then we can easily collapse down without having to do crazy
stuff. In addition people adding new features don't need
to have to go touch a million places in the code.
This is the start of this abstraction. In this commit
we'll just pull out the fd and input/output buffers
into a connection data structure. Future commits
will abstract further.
Keelan10 [Thu, 17 Aug 2023 16:42:11 +0000 (20:42 +0400)]
bgpd: Free memory in set_aspath_replace_access_list
Properly free the dynamically allocated memory held by `str` after its use.
The change also maintains the return value of `nb_cli_apply_changes` by using 'ret' variable.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_set_aspath_replace.test_bgp_set_aspath_replace/r1.asan.bgpd.11586
Direct leak of 92 byte(s) in 3 object(s) allocated from:
#0 0x7f4e2951db40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f4e28f19ea2 in qmalloc lib/memory.c:100
#2 0x7f4e28edbb08 in frrstr_join lib/frrstr.c:89
#3 0x7f4e28e9a601 in argv_concat lib/command.c:183
#4 0x56519adf8413 in set_aspath_replace_access_list_magic bgpd/bgp_routemap.c:6174
#5 0x56519adf8942 in set_aspath_replace_access_list bgpd/bgp_routemap_clippy.c:683
#6 0x7f4e28e9d548 in cmd_execute_command_real lib/command.c:993
#7 0x7f4e28e9da0c in cmd_execute_command lib/command.c:1051
#8 0x7f4e28e9de8b in cmd_execute lib/command.c:1218
#9 0x7f4e28fc4f1c in vty_command lib/vty.c:591
#10 0x7f4e28fc53c7 in vty_execute lib/vty.c:1354
#11 0x7f4e28fcdc8d in vtysh_read lib/vty.c:2362
#12 0x7f4e28fb8c8b in event_call lib/event.c:1979
#13 0x7f4e28efd445 in frr_run lib/libfrr.c:1213
#14 0x56519ac85d81 in main bgpd/bgp_main.c:510
#15 0x7f4e27f40c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 92 byte(s) leaked in 3 allocation(s).
***********************************************************************************
***********************************************************************************
Address Sanitizer Error detected in bgp_set_aspath_exclude.test_bgp_set_aspath_exclude/r1.asan.bgpd.10385
Direct leak of 55 byte(s) in 2 object(s) allocated from:
#0 0x7f6814fdab40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f68149d6ea2 in qmalloc lib/memory.c:100
#2 0x7f6814998b08 in frrstr_join lib/frrstr.c:89
#3 0x7f6814957601 in argv_concat lib/command.c:183
#4 0x5570e05117a1 in set_aspath_exclude_access_list_magic bgpd/bgp_routemap.c:6327
#5 0x5570e05119da in set_aspath_exclude_access_list bgpd/bgp_routemap_clippy.c:836
#6 0x7f681495a548 in cmd_execute_command_real lib/command.c:993
#7 0x7f681495aa0c in cmd_execute_command lib/command.c:1051
#8 0x7f681495ae8b in cmd_execute lib/command.c:1218
#9 0x7f6814a81f1c in vty_command lib/vty.c:591
#10 0x7f6814a823c7 in vty_execute lib/vty.c:1354
#11 0x7f6814a8ac8d in vtysh_read lib/vty.c:2362
#12 0x7f6814a75c8b in event_call lib/event.c:1979
#13 0x7f68149ba445 in frr_run lib/libfrr.c:1213
#14 0x5570e03a0d81 in main bgpd/bgp_main.c:510
#15 0x7f68139fdc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 55 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Donald Sharp [Mon, 14 Aug 2023 19:06:30 +0000 (15:06 -0400)]
zebra: Fix crashes in interface change
Upon some internal testing some crashes were found. This fixes
the several crashes and normalizes the code to be closer in
it's execution pre and post changes to use the data plane.
Problem:
On GR helper, paths learnt from an interface based peer were linked
to bnc with ifindex=0. During restart of GR peer, BGP (unnumbered)
session (with GR restarter peer) goes down on GR helper but the routes
are retained. Later, when BGP receives an interface up event, it
will process all the paths associated with BNC whose ifindex matches the
ifindex of the interface for which UP event is received. However, paths
associated with bnc that has ifindex=0 were not being reinstalled since
ifindex=0 doesn't match ifindex of any interfaces. This results in
BGP routes not being reinstalled in zebra and kernel.
Fix:
For paths learnt from an interface based peer, set the
ifindex to peer's interface ifindex so that correct
peer based nexthop can be found and linked to the path.
Signed-off-by: Donald Sharp sharpd@nvidia.com Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Renato Westphal [Fri, 11 Aug 2023 23:33:19 +0000 (20:33 -0300)]
ospf6d: introduce OSPFv3 Cryptographic Protocol ID constant
Create a constant OSPFV3_CRYPTO_PROTO_ID to replace the hard-coded
Cryptographic Protocol ID in the OSPFv3 authentication trailer
code. This enhances code clarity and maintainability.
Renato Westphal [Fri, 4 Aug 2023 12:03:02 +0000 (09:03 -0300)]
ospf6d: fix interoperability issue in auth trailer digest computation
Ensure the OSPFv3 Cryptographic Protocol ID is encoded in network
byte order when appending it to the authentication key. This solves
interoperability issues with other implementations such as BIRD
and IOS-XR.
G. Paul Ziemba [Sun, 13 Aug 2023 20:55:06 +0000 (13:55 -0700)]
pbrd: add advisory flag PBR_ACTION_DROP
PBR configuration may specify "set nexthop blackhole" which,
for linux dataplanes, is implemented as a table with a blackhole
route.
Other dataplanes might implement this action as an explicit
packet-filtering "drop" action instead of a route. This new flag
PBR_ACTION_DROP is now set when a rule has "set nexthop blackhole"
as an aid to other dataplanes.
Donatas Abraitis [Wed, 16 Aug 2023 08:14:39 +0000 (11:14 +0300)]
bgpd: Treat-as-withdraw attribute if remaining data is not enough
Relax this handling (RFC 7606) only for eBGP peers.
More details: https://datatracker.ietf.org/doc/html/rfc7606#section-4
There are two error cases in which the Total Attribute Length value
can be in conflict with the enclosed path attributes, which
themselves carry length values:
* In the first case, the length of the last encountered path
attribute would cause the Total Attribute Length to be exceeded
when parsing the enclosed path attributes.
* In the second case, fewer than three octets remain (or fewer than
four octets, if the Attribute Flags field has the Extended Length
bit set) when beginning to parse the attribute. That is, this
case exists if there remains unconsumed data in the path
attributes but yet insufficient data to encode a single minimum-
sized path attribute. <<<< HANDLING THIS CASE IN THIS COMMIT >>>>
In either of these cases, an error condition exists and the "treat-
as-withdraw" approach MUST be used (unless some other, more severe
error is encountered dictating a stronger approach), and the Total
Attribute Length MUST be relied upon to enable the beginning of the
NLRI field to be located.
Donatas Abraitis [Wed, 16 Aug 2023 05:37:23 +0000 (08:37 +0300)]
bgpd: Fix CLI descriptions for `bgp confederation identifier`
Before the patch:
```
donatas-laptop(config-router)# bgp confederation
identifier AS number in plain <1-4294967295> or dotted <0-65535>.<0-65535> format
peers Peer ASs in BGP confederation
```
Donald Sharp [Sat, 12 Aug 2023 15:29:37 +0000 (11:29 -0400)]
pimd: Intentionally rescan oil when RPF fails on upstream creation
When pim is creating an upstream for a S,G that it has received
*but* it has not received a route to the S, the oil is not
scanned to see if it should inherit anything from the *,G
that may be present when it cannot find the correct iif to
use. When the nexthop tracking actually
resolves the route, the oil is never rescanned and the
S,G stream will be missing a correct oil list leading
to absolute mayhem in the network.
Donald Sharp [Sat, 12 Aug 2023 04:14:00 +0000 (00:14 -0400)]
pimd: Allow more immediate null registers to be sent in the vxlan code
When a pim vxlan S,G is created, the code attempts to send out a NULL
register. This is used to build the S,G tree from the RP to the
FHR. Upon initial startup it is not unusual for the pim vxlan state
be fully ready to go but the RP is still not reachable. Let's add
a bit of a pump prime that allows the vxlan code to re-attempt to
send the null register for vxlan S,G's that the RP's outgoing
interface changed from unknown to an actual interface.
bgpd: Fix update message error handling for multiple same attributes
As per RFC7606 section 3g,
g. If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760]
attribute appears more than once in the UPDATE message, then a
NOTIFICATION message MUST be sent with the Error Subcode
"Malformed Attribute List". If any other attribute (whether
recognized or unrecognized) appears more than once in an UPDATE
message, then all the occurrences of the attribute other than the
first one SHALL be discarded and the UPDATE message will continue
to be processed.
However, notification is sent out currently for all the cases.
Fix:
For cases other than MP_REACH_NLRI & MP_UNREACH_NLRI, handling has been updated
to discard the occurrences other than the first one and proceed with further parsing.
Again, the handling is relaxed only for the EBGP case.
Also, since in case of error, the attribute is discarded &
stream pointer is being adjusted accordingly based on length,
the total attribute length sanity check case has been moved up in the function
to be checked before this case.
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
bgpd: Fix update message error handling for total attribute length
As per RFC7606 section 4,
when the total attribute length value is in conflict with the
enclosed attribute length, treat-as-withdraw approach must be followed.
However, notification is being sent out for this case currently,
that leads to session reset.
Fix:
The handling has been updated to conform to treat-as-withdraw
approach only for EBGP case. For IBGP, since we are not following
treat-as-withdraw approach for any of the error handling cases,
the existing behavior is retained for the IBGP.
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
Keelan10 [Mon, 29 May 2023 05:50:17 +0000 (09:50 +0400)]
zebra: Delete the 'mbr_zifs' list in the if_zebra_delete_hook function
This commit addresses a memory leak issue detected by ASan associated with the member lists (mbr_zifs) of bond interfaces.
Previously, the member lists were not properly deleted during interface deletion, leading to memory leaks.
A call to list_delete() is made when interface is deleted.
The ASan leak log for reference:
```
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047:Direct leak of 80 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- #0 0x7fe7a5b9d037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#1 0x7fe7a57431ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#2 0x7fe7a571833c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#3 0x55c1b87a7525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#4 0x55c1b86e044d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#5 0x55c1b870fbcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#6 0x55c1b86e0cc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#7 0x55c1b86e8b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#8 0x55c1b8817a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#9 0x55c1b8817e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#10 0x55c1b8717b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#11 0x7fe7a5231d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047-
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- #0 0x7fe7a5b9d037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#1 0x7fe7a57431ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#2 0x7fe7a571843d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#3 0x7fe7a5718780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#4 0x55c1b87a6fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#5 0x55c1b86f177d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#6 0x55c1b86e0d51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#7 0x55c1b86e8b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#8 0x55c1b8817a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#9 0x55c1b8817e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#10 0x55c1b8717b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#11 0x7fe7a5231d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047-
./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918:Direct leak of 80 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- #0 0x7fd8c357f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#1 0x7fd8c31251ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#2 0x7fd8c30fa33c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#3 0x56101df23525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#4 0x56101de5c44d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#5 0x56101de8bbcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#6 0x56101de5ccc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#7 0x56101de64b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#8 0x56101df93a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#9 0x56101df93e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#10 0x56101de93b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#11 0x7fd8c2c13d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918-
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- #0 0x7fd8c357f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#1 0x7fd8c31251ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#2 0x7fd8c30fa43d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#3 0x7fd8c30fa780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#4 0x56101df22fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#5 0x56101de6d77d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#6 0x56101de5cd51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#7 0x56101de64b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#8 0x56101df93a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#9 0x56101df93e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#10 0x56101de93b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#11 0x7fd8c2c13d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918-
./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815:Direct leak of 80 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- #0 0x7ff74228b037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#1 0x7ff741e311ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#2 0x7ff741e0633c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#3 0x56535dceb525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#4 0x56535dc2444d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#5 0x56535dc53bcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#6 0x56535dc24cc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#7 0x56535dc2cb27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#8 0x56535dd5ba77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#9 0x56535dd5be76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#10 0x56535dc5bb38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#11 0x7ff74191fd09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815-
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- #0 0x7ff74228b037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#1 0x7ff741e311ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#2 0x7ff741e0643d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#3 0x7ff741e06780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#4 0x56535dceafdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#5 0x56535dc3577d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#6 0x56535dc24d51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#7 0x56535dc2cb27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#8 0x56535dd5ba77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#9 0x56535dd5be76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#10 0x56535dc5bb38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#11 0x7ff74191fd09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815-
./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685:Direct leak of 40 byte(s) in 1 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- #0 0x7fb3bf09f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#1 0x7fb3bec451ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#2 0x7fb3bec1a33c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#3 0x559e90ee6525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#4 0x559e90e1f44d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#5 0x559e90e4ebcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#6 0x559e90e1fcc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#7 0x559e90e27b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#8 0x559e90f56a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#9 0x559e90f56e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#10 0x559e90e56b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#11 0x7fb3be733d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685-
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- #0 0x7fb3bf09f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#1 0x7fb3bec451ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#2 0x7fb3bec1a43d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#3 0x7fb3bec1a780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#4 0x559e90ee5fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#5 0x559e90e3077d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#6 0x559e90e1fd51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#7 0x559e90e27b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#8 0x559e90f56a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#9 0x559e90f56e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#10 0x559e90e56b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#11 0x7fb3be733d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685-
./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560:Direct leak of 40 byte(s) in 1 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- #0 0x7faab58d4037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#1 0x7faab547a1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#2 0x7faab544f33c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#3 0x5599ef7e5525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#4 0x5599ef71e44d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#5 0x5599ef74dbcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#6 0x5599ef71ecc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#7 0x5599ef726b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#8 0x5599ef855a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#9 0x5599ef855e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#10 0x5599ef755b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#11 0x7faab4f68d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560-
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- #0 0x7faab58d4037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#1 0x7faab547a1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#2 0x7faab544f43d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#3 0x7faab544f780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#4 0x5599ef7e4fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#5 0x5599ef72f77d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#6 0x5599ef71ed51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#7 0x5599ef726b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#8 0x5599ef855a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#9 0x5599ef855e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#10 0x5599ef755b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#11 0x7faab4f68d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560-
./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413:Direct leak of 80 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- #0 0x7fc5e175f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#1 0x7fc5e13051ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#2 0x7fc5e12da33c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#3 0x55e090b90525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#4 0x55e090ac944d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#5 0x55e090af8bcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#6 0x55e090ac9cc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#7 0x55e090ad1b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#8 0x55e090c00a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#9 0x55e090c00e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#10 0x55e090b00b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#11 0x7fc5e0df3d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413-
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- #0 0x7fc5e175f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#1 0x7fc5e13051ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#2 0x7fc5e12da43d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#3 0x7fc5e12da780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#4 0x55e090b8ffdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#5 0x55e090ada77d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#6 0x55e090ac9d51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#7 0x55e090ad1b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#8 0x55e090c00a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#9 0x55e090c00e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#10 0x55e090b00b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#11 0x7fc5e0df3d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413-
./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024:Direct leak of 40 byte(s) in 1 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- #0 0x7fe5c2019037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#1 0x7fe5c1bbf1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#2 0x7fe5c1b9433c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#3 0x557ad92d0525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#4 0x557ad920944d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#5 0x557ad9238bcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#6 0x557ad9209cc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#7 0x557ad9211b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#8 0x557ad9340a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#9 0x557ad9340e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#10 0x557ad9240b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#11 0x7fe5c16add09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024-
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- #0 0x7fe5c2019037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#1 0x7fe5c1bbf1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#2 0x7fe5c1b9443d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#3 0x7fe5c1b94780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#4 0x557ad92cffdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#5 0x557ad921a77d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#6 0x557ad9209d51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#7 0x557ad9211b27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#8 0x557ad9340a77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#9 0x557ad9340e76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#10 0x557ad9240b38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#11 0x7fe5c16add09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024-
./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s).
--
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551:Direct leak of 40 byte(s) in 1 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- #0 0x7f1fc2399037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#1 0x7f1fc1f3f1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#2 0x7f1fc1f1433c in list_new lib/linklist.c:49
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#3 0x559cd8f0b525 in zebra_l2if_update_bond zebra/zebra_l2.c:223
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#4 0x559cd8e4444d in netlink_interface zebra/if_netlink.c:1203
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#5 0x559cd8e73bcf in netlink_parse_info zebra/kernel_netlink.c:1183
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#6 0x559cd8e44cc1 in interface_lookup_netlink zebra/if_netlink.c:1273
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#7 0x559cd8e4cb27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#8 0x559cd8f7ba77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#9 0x559cd8f7be76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#10 0x559cd8e7bb38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#11 0x7f1fc1a2dd09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551-
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551:Indirect leak of 48 byte(s) in 2 object(s) allocated from:
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- #0 0x7f1fc2399037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#1 0x7f1fc1f3f1ee in qcalloc lib/memory.c:105
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#2 0x7f1fc1f1443d in listnode_new lib/linklist.c:71
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#3 0x7f1fc1f14780 in listnode_add lib/linklist.c:92
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#4 0x559cd8f0afdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#5 0x559cd8e5577d in zebra_if_update_all_links zebra/interface.c:1150
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#6 0x559cd8e44d51 in interface_lookup_netlink zebra/if_netlink.c:1303
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#7 0x559cd8e4cb27 in interface_list zebra/if_netlink.c:2419
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#8 0x559cd8f7ba77 in zebra_ns_enable zebra/zebra_ns.c:113
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#9 0x559cd8f7be76 in zebra_ns_init zebra/zebra_ns.c:205
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#10 0x559cd8e7bb38 in main zebra/main.c:399
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#11 0x7f1fc1a2dd09 in __libc_start_main ../csu/libc-start.c:308
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551-
./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s).
```
Donald Sharp [Sat, 12 Aug 2023 04:06:51 +0000 (00:06 -0400)]
pimd: Prevent vxlan from causing a S,G RPT Prune in some cases
Upon startup the pim vxlan code initiates a pim null register
send for the S,G and sends a *,G join towards the RP at the same
time. Since a S,G upstream is created in the vxlan code with
the appropriate flags, the *,G join has the embedded S,G RPT
Prune. When an intermediate route receives this *,G RPT Prune
it creates a blackhole S,G route since this particular intermediate
router has not received a join from the RP yet( say the packet is
lost, or that part of the network is slower coming up ).
Let's try to intelligently decide that the S,G RPT Prune
should not be sent as part of the *,G join until the actual
S,G join from the RP reaches this box. Then we can make
intelligent decisions about whether or not to send it
out.
projects / mirror / frr.git / log