-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isis crash #4
Comments
do we have some pcap files for this? |
output.swp2.pcap.gz Multiple iterations of the crash hopefully included in the 2 pcap files. This is on r11 |
Valgrind caught it this time: ==7946== Invalid free() / delete / delete[] / realloc() |
So in isis_tlv.c we have this:
#ifdef EXTREME_TLV_DEBUG pnt is set off the stream_dup that lsp->pdu is set from, but we have a lsp->own_lsp set to true hence the crash. |
Commit 4fedc05 addresses the issue from happening. But I would like to see Christian comment on the further debugging I provided before closing to see if he thinks what he has done has sufficiently closed the loop holes. |
actually I was wrong, I just happened to recheck my test setup and am seeing the same core files. |
Resolved via 07f2fb1 |
* commit '4709b4faa43907ed9fcaf5920e56b6664f0523cf': bgpd: peer hash expands until we are out of memory
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-17175 If you are doing multipath in a VRF and bounce one of the multipaths for a prefix, bgp is not updating the zebra entry for that prefix with the new multipaths. We start with: cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32 BGP routing table entry for 6.0.0.16/32 Paths: (4 available, best #4, table RED) Advertised to non peer-group peers: spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4) 104 65104 65002 fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12) (fe80::202:ff:fe00:2d) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104 AddPath ID: RX 0, TX 21 Last update: Tue Aug 1 18:28:33 2017 102 65104 65002 fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10) (fe80::202:ff:fe00:25) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102 AddPath ID: RX 0, TX 20 Last update: Tue Aug 1 18:28:33 2017 103 65104 65002 fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11) (fe80::202:ff:fe00:29) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103 AddPath ID: RX 0, TX 17 Last update: Tue Aug 1 18:28:33 2017 101 65104 65002 fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9) (fe80::202:ff:fe00:21) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best AddPath ID: RX 0, TX 8 Last update: Tue Aug 1 18:28:33 2017 cel-redxp-10# cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:25 ago * fe80::202:ff:fe00:21, via swp1 * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# And then on spine-1 we bounce all peers spine-1# clear ip bgp * spine-1# On the leaf (cel-redxp-10) we remove the route from spine-1 cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:01 ago * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# So far so good. The problem is when the session to spine-1 comes back up bgp will mark the flag from spine-1 as multipath but does not update zebra. We end up in a state where BGP has 4 paths flags as multipath but only 3 paths are in the RIB.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> If you are doing multipath in a VRF and bounce one of the multipaths for a prefix, bgp is not updating the zebra entry for that prefix with the new multipaths. We start with: cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32 BGP routing table entry for 6.0.0.16/32 Paths: (4 available, best #4, table RED) Advertised to non peer-group peers: spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4) 104 65104 65002 fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12) (fe80::202:ff:fe00:2d) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104 AddPath ID: RX 0, TX 21 Last update: Tue Aug 1 18:28:33 2017 102 65104 65002 fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10) (fe80::202:ff:fe00:25) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102 AddPath ID: RX 0, TX 20 Last update: Tue Aug 1 18:28:33 2017 103 65104 65002 fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11) (fe80::202:ff:fe00:29) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103 AddPath ID: RX 0, TX 17 Last update: Tue Aug 1 18:28:33 2017 101 65104 65002 fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9) (fe80::202:ff:fe00:21) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best AddPath ID: RX 0, TX 8 Last update: Tue Aug 1 18:28:33 2017 cel-redxp-10# cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:25 ago * fe80::202:ff:fe00:21, via swp1 * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# And then on spine-1 we bounce all peers spine-1# clear ip bgp * spine-1# On the leaf (cel-redxp-10) we remove the route from spine-1 cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:01 ago * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# So far so good. The problem is when the session to spine-1 comes back up bgp will mark the flag from spine-1 as `multipath` but does not update zebra. We end up in a state where BGP has 4 paths flags as multipath but only 3 paths are in the RIB.
More error stuff
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When staticd receives a `ZAPI_SRV6_SID_RELEASED` notification from SRv6 SID Manager, it tries to unset the validity flag of `sid`. But since the `sid` variable is NULL, we get a NULL pointer dereference. ``` ================================================================= ==13815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000060 (pc 0xc14b813d9eac bp 0xffffcb135a40 sp 0xffffcb135a40 T0) ==13815==The signal is caused by a READ memory access. ==13815==Hint: address points to the zero page. #0 0xc14b813d9eac in static_zebra_srv6_sid_notify staticd/static_zebra.c:1172 #1 0xe44e7aa2c194 in zclient_read lib/zclient.c:4746 FRRouting#2 0xe44e7a9b69d8 in event_call lib/event.c:1984 FRRouting#3 0xe44e7a85ac28 in frr_run lib/libfrr.c:1246 FRRouting#4 0xc14b813ccf98 in main staticd/static_main.c:193 FRRouting#5 0xe44e7a4773f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#6 0xe44e7a4774c8 in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#7 0xc14b813cc92c in _start (/usr/lib/frr/staticd+0x1c92c) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV staticd/static_zebra.c:1172 in static_zebra_srv6_sid_notify ==13815==ABORTING ``` This commit fixes the problem by doing a SID lookup first. If the SID can't be found, we log an error and return. If the SID is found, we go ahead and unset the validity flag. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > #8 0x7f358e98082d in event_call lib/event.c:1996 > #9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > #8 0x7f358e98082d in event_call lib/event.c:1996 > #9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > #8 0x7f358e98082d in event_call lib/event.c:1996 > #9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Upon reconfiguration of the default instance, free the previous pointer. > ================================================================= > ==1209420==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fbde0eaa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fbde0874634 in qcalloc lib/memory.c:106 > #2 0x55dcca019263 in bgp_rtc_plist_entry_asn_new bgpd/bgp_rtc.c:474 > #3 0x55dcca0199f6 in bgp_rtc_plist_entry_add bgpd/bgp_rtc.c:556 > FRRouting#4 0x55dcca01b078 in bgp_rtc_plist_entry_set bgpd/bgp_rtc.c:700 > FRRouting#5 0x55dcca016421 in bgp_nlri_parse_rtc bgpd/bgp_rtc.c:56 > FRRouting#6 0x55dcc9f39f61 in bgp_nlri_parse bgpd/bgp_packet.c:352 > FRRouting#7 0x55dcc9f47628 in bgp_update_receive bgpd/bgp_packet.c:2485 > FRRouting#8 0x55dcc9f54867 in bgp_process_packet bgpd/bgp_packet.c:4114 > FRRouting#9 0x7fbde097aebc in event_call lib/event.c:1984 > FRRouting#10 0x7fbde084710f in frr_run lib/libfrr.c:1246 > FRRouting#11 0x55dcc9dd818b in main bgpd/bgp_main.c:557 > FRRouting#12 0x7fbde044fd79 in __libc_start_main ../csu/libc-start.c:308 Fixes: 4d0e7a4 ("bgpd: VRF-Lite fix default bgp delete") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
…ion mode The following configuration commands trigger a crash of the BGP daemon: > ipv6 route ff12::/64 fec0::6 > router bgp 65500 > address-family ipv6 unicast > label vpn export auto > rd vpn export 22:2 > rt vpn import 22:2 > rt vpn export 22:22 > network ff12::/64 > export vpn > label vpn export allocation-mode per-nexthop > no network ff12::/64 > The following backtrace extract can be seen. > Signal: 11 (SEGV) > [..] >FRRouting#4 0x00007fef4d51b711 in core_handler (signo=11, siginfo=0x7ffe9b70c170, context=0x7ffe9b70c040) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262 >FRRouting#5 <signal handler called> >FRRouting#6 bgp_label_per_nexthop_send_nexthop_label (blnc=0x55fb67ebfcf0, cmd=46) > at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_labelpool.c:1158 >FRRouting#7 0x000055fb66bcba61 in bgp_mplsvpn_get_label_per_nexthop_cb (label=81, context=0x55fb67ebfcf0, > allocated=true) at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_mplsvpn.c:765 >FRRouting#8 0x000055fb66bbde4a in lp_cbq_docallback (wq=0x55fb678e64e0, data=0x55fb678c8580) > at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_labelpool.c:112 We are trying to access the 'blnc' memory zone that has been freed. The 'blnc' memory zone is the label next-hop cache entry context that stores the list of paths that use the same label value. When configuring a network in an L3VPN instance, when the 'per-nexthop' allocation mode is used, any declared network that has an identified next-hop triggers a label request. The label request is always asynchronous, and when a label is obtained, a callback is called, with the label and the 'blnc' pointer passed as parameters. If, in the meantime, the declared network is un-configured, then the 'blnc' context may be freed and becomes invalid. Do free the blnc pointer only when the callback is requested: - A flag indicates that there is a label allocation in progress. When a free is detected, unset this flag, and detach the blnc from the label next-hop cache hash list. - When the requester is called back, if the flag is unset, the 'blnc' context is freed. Fixes: ("577be36a41be") bgpd: add support for l3vpn per-nexthop label Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
…ion mode The following configuration commands trigger a crash of the BGP daemon: > ipv6 route ff12::/64 fec0::6 > router bgp 65500 > address-family ipv6 unicast > label vpn export auto > rd vpn export 22:2 > rt vpn import 22:2 > rt vpn export 22:22 > network ff12::/64 > export vpn > label vpn export allocation-mode per-nexthop > no network ff12::/64 > The following backtrace extract can be seen. > Signal: 11 (SEGV) > [..] >FRRouting#4 0x00007fef4d51b711 in core_handler (signo=11, siginfo=0x7ffe9b70c170, context=0x7ffe9b70c040) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262 >FRRouting#5 <signal handler called> >FRRouting#6 bgp_label_per_nexthop_send_nexthop_label (blnc=0x55fb67ebfcf0, cmd=46) > at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_labelpool.c:1158 >FRRouting#7 0x000055fb66bcba61 in bgp_mplsvpn_get_label_per_nexthop_cb (label=81, context=0x55fb67ebfcf0, > allocated=true) at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_mplsvpn.c:765 >FRRouting#8 0x000055fb66bbde4a in lp_cbq_docallback (wq=0x55fb678e64e0, data=0x55fb678c8580) > at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_labelpool.c:112 We are trying to access the 'blnc' memory zone that has been freed. The 'blnc' memory zone is the label next-hop cache entry context that stores the list of paths that use the same label value. When configuring a network in an L3VPN instance, when the 'per-nexthop' allocation mode is used, any declared network that has an identified next-hop triggers a label request. The label request is always asynchronous, and when a label is obtained, a callback is called, with the label and the 'blnc' pointer passed as parameters. If, in the meantime, the declared network is un-configured, then the 'blnc' context may be freed and becomes invalid. Do free the blnc pointer only when the callback is requested: - A flag indicates that there is a label allocation in progress. When a free is detected, unset this flag, and detach the blnc from the label next-hop cache hash list. - When the requester is called back, if the flag is unset, the 'blnc' context is freed. Fixes: ("577be36a41be") bgpd: add support for l3vpn per-nexthop label Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon reconfiguration of the default instance, free the previous pointer. > ================================================================= > ==1209420==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fbde0eaa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fbde0874634 in qcalloc lib/memory.c:106 > #2 0x55dcca019263 in bgp_rtc_plist_entry_asn_new bgpd/bgp_rtc.c:474 > #3 0x55dcca0199f6 in bgp_rtc_plist_entry_add bgpd/bgp_rtc.c:556 > FRRouting#4 0x55dcca01b078 in bgp_rtc_plist_entry_set bgpd/bgp_rtc.c:700 > FRRouting#5 0x55dcca016421 in bgp_nlri_parse_rtc bgpd/bgp_rtc.c:56 > FRRouting#6 0x55dcc9f39f61 in bgp_nlri_parse bgpd/bgp_packet.c:352 > FRRouting#7 0x55dcc9f47628 in bgp_update_receive bgpd/bgp_packet.c:2485 > FRRouting#8 0x55dcc9f54867 in bgp_process_packet bgpd/bgp_packet.c:4114 > FRRouting#9 0x7fbde097aebc in event_call lib/event.c:1984 > FRRouting#10 0x7fbde084710f in frr_run lib/libfrr.c:1246 > FRRouting#11 0x55dcc9dd818b in main bgpd/bgp_main.c:557 > FRRouting#12 0x7fbde044fd79 in __libc_start_main ../csu/libc-start.c:308 Fixes: 4d0e7a4 ("bgpd: VRF-Lite fix default bgp delete") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Upon reconfiguration of the default instance, free the previous pointer. > ================================================================= > ==1209420==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fbde0eaa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fbde0874634 in qcalloc lib/memory.c:106 > #2 0x55dcca019263 in bgp_rtc_plist_entry_asn_new bgpd/bgp_rtc.c:474 > #3 0x55dcca0199f6 in bgp_rtc_plist_entry_add bgpd/bgp_rtc.c:556 > FRRouting#4 0x55dcca01b078 in bgp_rtc_plist_entry_set bgpd/bgp_rtc.c:700 > FRRouting#5 0x55dcca016421 in bgp_nlri_parse_rtc bgpd/bgp_rtc.c:56 > FRRouting#6 0x55dcc9f39f61 in bgp_nlri_parse bgpd/bgp_packet.c:352 > FRRouting#7 0x55dcc9f47628 in bgp_update_receive bgpd/bgp_packet.c:2485 > FRRouting#8 0x55dcc9f54867 in bgp_process_packet bgpd/bgp_packet.c:4114 > FRRouting#9 0x7fbde097aebc in event_call lib/event.c:1984 > FRRouting#10 0x7fbde084710f in frr_run lib/libfrr.c:1246 > FRRouting#11 0x55dcc9dd818b in main bgpd/bgp_main.c:557 > FRRouting#12 0x7fbde044fd79 in __libc_start_main ../csu/libc-start.c:308 Fixes: 4d0e7a4 ("bgpd: VRF-Lite fix default bgp delete") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
[6:35]
[6:35]
[6:36]
In the above topology we are seeing crashes in isis on r11, r4, and r7
[6:36]
config on r10:
[6:37]
The text was updated successfully, but these errors were encountered: