all: use ->text when parsing protocol argument #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
and match on full protocol name in proto_redistnum() Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Continous Integration Result: FAILEDSee below for issues. This is a comment from an EXPERIMENTAL automated CI system. Get source and apply patch from patchwork: SuccessfulBuilding Stage: FailedFedora24 amd64 build: Successful CentOS6 amd64 build: FailedCentOS6 amd64 build: Unknown Log <log_configure.txt> FreeBSD10 amd64 build: FailedDejaGNU Unittests (make check) failed for FreeBSD10 amd64 build Ubuntu1204 amd64 build: FailedUbuntu1204 amd64 build: Unknown Log <log_configure.txt> |
Continous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-23/ This is a comment from an EXPERIMENTAL automated CI system. |
qlyoung
added a commit
to qlyoung/frr
that referenced
this pull request
Apr 2, 2017
proto_redistnum() now accepts full protocol strings and not partial names per FRRouting#10 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This was referenced Sep 5, 2017
Merged
This was referenced May 14, 2018
rwestphal
referenced
this pull request
in opensourcerouting/frr
Feb 21, 2019
If path->net is NULL in the bgp_path_info_free() function, then bgpd would crash in bgp_addpath_free_info_data() with the following backtrace: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ff7b267a42a in __GI_abort () at abort.c:89 #2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249 #3 <signal handler called> #4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368 #5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100 #6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252 #7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276 #8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320 #9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476 #10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 #11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 #12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 #13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 #14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481 Add a null-check protection to fix this problem. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 13, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 14, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 14, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 16, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 16, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 20, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 20, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 21, 2025
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
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 21, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 21, 2025
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>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 21, 2025
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>
RodrigoMNardi
pushed a commit
to RodrigoMNardi/frr
that referenced
this pull request
Jan 27, 2025
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>
RodrigoMNardi
pushed a commit
to RodrigoMNardi/frr
that referenced
this pull request
Jan 27, 2025
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>
2 tasks
riw777
pushed a commit
that referenced
this pull request
Feb 4, 2025
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>
riw777
pushed a commit
that referenced
this pull request
Feb 4, 2025
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>
riw777
pushed a commit
that referenced
this pull request
Feb 5, 2025
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>
louis-6wind
added a commit
to louis-6wind/frr
that referenced
this pull request
Feb 12, 2025
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>
louis-6wind
added a commit
to louis-6wind/frr
that referenced
this pull request
Feb 14, 2025
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>
louis-6wind
added a commit
to louis-6wind/frr
that referenced
this pull request
Feb 14, 2025
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>
louis-6wind
added a commit
to louis-6wind/frr
that referenced
this pull request
Mar 5, 2025
Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
routingrocks
added a commit
to routingrocks/frr
that referenced
this pull request
Mar 7, 2025
Issue:
When we call zebra_neigh_del(ifp, &n->ip), it eventully frees
neighbor n zebra_neigh_free(n). when we call RB_FOREACH_SAFE()
it tries to use the n after its freed.
Fix: not accessing n after its freed.
This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
#0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
FRRouting#1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
FRRouting#2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
FRRouting#3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
FRRouting#4 0x55f95a0f819d in if_down zebra/interface.c:1017
FRRouting#5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
FRRouting#6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
FRRouting#7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
FRRouting#8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
FRRouting#9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
FRRouting#10 0x55f95a11ca7f in main zebra/main.c:543
FRRouting#11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
FRRouting#13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)
Ticket: FRRouting#18047
louis-6wind
added a commit
to louis-6wind/frr
that referenced
this pull request
Mar 10, 2025
Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
routingrocks
added a commit
to routingrocks/frr
that referenced
this pull request
Mar 11, 2025
Issue:
Not freeing the neighbor n within the same function can lead to
memory leak.
zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free
Fix: not accessing n after its freed.
Directly free the neighbor entry (n) when its interface index matches
ifp->ifindex.
This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
#0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
FRRouting#1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
FRRouting#2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
FRRouting#3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
FRRouting#4 0x55f95a0f819d in if_down zebra/interface.c:1017
FRRouting#5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
FRRouting#6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
FRRouting#7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
FRRouting#8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
FRRouting#9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
FRRouting#10 0x55f95a11ca7f in main zebra/main.c:543
FRRouting#11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
FRRouting#13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)
Ticket: FRRouting#18047
routingrocks
added a commit
to routingrocks/frr
that referenced
this pull request
Mar 11, 2025
Issue:
Not freeing the neighbor n within the same function can lead to
memory leak.
zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free
Fix: not accessing n after its freed.
Directly free the neighbor entry (n) when its interface index matches
ifp->ifindex.
This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
#0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
FRRouting#1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
FRRouting#2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
FRRouting#3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
FRRouting#4 0x55f95a0f819d in if_down zebra/interface.c:1017
FRRouting#5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
FRRouting#6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
FRRouting#7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
FRRouting#8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
FRRouting#9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
FRRouting#10 0x55f95a11ca7f in main zebra/main.c:543
FRRouting#11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
FRRouting#13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)
Ticket: FRRouting#18047
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Tuetuopay
added a commit
to Tuetuopay/frr
that referenced
this pull request
Mar 17, 2025
With soft reconfiguration, the BGP attributes are interned, but the EVPN
attributes contained by the standard attributes are also interned.
However, during BGP route processing, we performed a copy of the
attributes in a new_attr struct, performing a shallow-copy. This made
two structs point to the same interned EVPN attributes, freeing the
attributes at the end of the input processing.
Fix the double-free by increasing the refcount when shallow-copying the
attributes.
The direct symptom can be seen with a topotest, where bgpd segfaults on
exit when cleaning up peer data:
(gdb) bt
FRRouting#12 0x00007fc57d6a8ff5 in malloc_printerr (str=str@entry=0x7fc57d7d18a0 "malloc_consolidate(): unaligned fastbin chunk detected") at ./malloc/malloc.c:5772
FRRouting#13 0x00007fc57d6a9d4c in malloc_consolidate (av=0x7fc57d803ac0 <main_arena>) at ./malloc/malloc.c:4846
FRRouting#14 0x00007fc57d6aada5 in _int_free_maybe_consolidate (av=0x7fc57d803ac0 <main_arena>, size=<optimized out>) at ./malloc/malloc.c:4779
FRRouting#15 0x00007fc57d6ab43a in _int_free (av=0x7fc57d803ac0 <main_arena>, p=<optimized out>, have_lock=<optimized out>) at ./malloc/malloc.c:4646
FRRouting#16 0x00007fc57d6addae in __GI___libc_free (mem=0x55704295e8a0) at ./malloc/malloc.c:3398
FRRouting#17 0x00007fc57dada55e in qfree (mt=mt@entry=0x7fc57dc34e60 <MTYPE_STREAM>, ptr=<optimized out>) at lib/memory.c:131
FRRouting#18 0x00007fc57db1b8f8 in stream_free (s=<optimized out>) at lib/stream.c:109
FRRouting#19 0x000055704186539e in sync_delete (subgrp=0x557042957f00) at bgpd/bgp_updgrp.c:108
FRRouting#20 update_subgroup_delete (subgrp=0x557042957f00) at bgpd/bgp_updgrp.c:1167
FRRouting#21 0x0000557041866c75 in update_subgroup_check_delete (subgrp=<optimized out>) at bgpd/bgp_updgrp.c:1202
FRRouting#22 0x00005570417fbf51 in update_group_remove_peer_afs (peer=<optimized out>) at ./bgpd/bgp_updgrp.h:523
FRRouting#23 bgp_stop (connection=<optimized out>) at bgpd/bgp_fsm.c:1478
FRRouting#24 0x0000557041800357 in bgp_event_update (connection=0x557042956b50, event=TCP_connection_closed) at bgpd/bgp_fsm.c:2655
FRRouting#25 0x00007fc57db28fae in event_call (thread=thread@entry=0x7ffe0c687760) at lib/event.c:2019
FRRouting#26 0x00007fc57daccb28 in frr_run (master=0x5570421106e0) at lib/libfrr.c:1247
FRRouting#27 0x00005570417b1fd3 in main (argc=<optimized out>, argv=0x7ffe0c687a28) at bgpd/bgp_main.c:557
Situation is even worse in real-world case where the route actually
leaves to other peers, as the free'd memory will quickly get
reallocated, trampled over, and trigger an assert on IP type (same one
as the previous route-map patch):
(gdb) bt
FRRouting#4 0x00007570922b1569 in _zlog_assert_failed (xref=xref@entry=0x5e9e11716280 <_xref.1>, extra=extra@entry=0x0) at ../lib/zlog.c:767
FRRouting#5 0x00005e9e114f005e in ipaddr_cmp (b=<optimized out>, a=<optimized out>) at ../lib/ipaddr.h:153
FRRouting#6 bgp_route_evpn_same (e1=<optimized out>, e2=<optimized out>) at ../bgpd/bgp_attr_evpn.c:36
FRRouting#7 0x00005e9e114e854b in overlay_index_same (a2=0x7ffc880779b0, a1=0x5e9e3cd16670) at ../bgpd/bgp_attr.h:632
FRRouting#8 attrhash_cmp (p1=0x5e9e3cd16670, p2=0x7ffc880779b0) at ../bgpd/bgp_attr.c:921
FRRouting#9 0x000075709222bd93 in hash_get (hash=0x5e9e3d1a3d70, data=data@entry=0x7ffc880779b0, alloc_func=alloc_func@entry=0x5e9e114e78a0 <bgp_attr_hash_alloc>) at ../lib/hash.c:142
FRRouting#10 0x00005e9e114e89f4 in bgp_attr_intern (attr=attr@entry=0x7ffc880779b0) at ../bgpd/bgp_attr.c:1134
FRRouting#11 0x00005e9e11621443 in bgp_advertise_attr_intern (hash=0x5e9e3d45bdc0, attr=attr@entry=0x7ffc880779b0) at ../bgpd/bgp_advertise.c:106
FRRouting#12 0x00005e9e1159317d in bgp_adj_out_set_subgroup (dest=dest@entry=0x5e9e3d45ca50, subgrp=subgrp@entry=0x5e9e3d45bcc0, attr=attr@entry=0x7ffc880779b0, path=path@entry=0x5e9e3d465010) at ../bgpd/bgp_updgrp_adv.c:618
FRRouting#13 0x00005e9e115666f1 in subgroup_process_announce_selected (subgrp=subgrp@entry=0x5e9e3d45bcc0, selected=<optimized out>, dest=0x5e9e3d45ca50, afi=afi@entry=AFI_L2VPN, safi=safi@entry=SAFI_EVPN, addpath_tx_id=0) at ../bgpd/bgp_route.c:3362
FRRouting#14 0x00005e9e11592a1f in group_announce_route_walkcb (updgrp=<optimized out>, arg=<optimized out>) at ../bgpd/bgp_updgrp_adv.c:260
FRRouting#15 0x000075709222c21a in hash_walk (hash=0x5e9e3d4390e0, func=func@entry=0x5e9e1158e3e0 <update_group_walkcb>, arg=arg@entry=0x7ffc88077be0) at ../lib/hash.c:270
FRRouting#16 0x00005e9e11591c77 in update_group_af_walk (bgp=bgp@entry=0x5e9e3d426eb0, afi=<optimized out>, safi=<optimized out>, cb=cb@entry=0x5e9e11592960 <group_announce_route_walkcb>, ctx=ctx@entry=0x7ffc88077c70) at ../bgpd/bgp_updgrp.c:2074
FRRouting#17 0x00005e9e115943e9 in group_announce_route (bgp=bgp@entry=0x5e9e3d426eb0, afi=afi@entry=AFI_L2VPN, safi=safi@entry=SAFI_EVPN, dest=dest@entry=0x5e9e3d45ca50, pi=pi@entry=0x5e9e3d465010) at ../bgpd/bgp_updgrp_adv.c:1119
FRRouting#18 0x00005e9e11562789 in bgp_process_main_one (bgp=bgp@entry=0x5e9e3d426eb0, dest=dest@entry=0x5e9e3d45ca50, afi=AFI_L2VPN, safi=SAFI_EVPN) at ../bgpd/bgp_route.c:3889
FRRouting#19 0x00005e9e11563088 in bgp_process_wq (wq=<optimized out>, data=0x5e9e3d467310) at ../bgpd/bgp_route.c:4015
FRRouting#20 0x000075709229eaa3 in work_queue_run (thread=0x7ffc88077ec0) at ../lib/workqueue.c:282
FRRouting#21 0x0000757092291d71 in event_call (thread=thread@entry=0x7ffc88077ec0) at ../lib/event.c:1996
FRRouting#22 0x000075709223a590 in frr_run (master=0x5e9e3cce2f10) at ../lib/libfrr.c:1232
FRRouting#23 0x00005e9e114e488e in main (argc=<optimized out>, argv=0x7ffc88078178) at ../bgpd/bgp_main.c:555
Indeed, the prefixes are complete garbage:
(gdb) up
FRRouting#7 0x00005e9e114e854b in overlay_index_same (a2=0x7ffc880779b0, a1=0x5e9e3cd16670) at ../bgpd/bgp_attr.h:632
(gdb) p/x a2->evpn_overlay->gw_ip
$2 = {ipa_type = 0x20, ip = {addr = 0x0, addrbytes = {0x0, 0x0, 0x0, 0x0, 0x41, 0xd4, 0xe3,
0xe9, 0x5, 0x0, 0x0, 0x0, 0xed, 0x46, 0xb2, 0x24}, _v4_addr = {s_addr = 0x0},
_v6_addr = {__in6_u = {__u6_addr8 = {0x0, 0x0, 0x0, 0x0, 0x41, 0xd4, 0xe3, 0xe9, 0x5,
0x0, 0x0, 0x0, 0xed, 0x46, 0xb2, 0x24}, __u6_addr16 = {0x0, 0x0, 0xd441, 0xe9e3,
0x5, 0x0, 0x46ed, 0x24b2}, __u6_addr32 = {0x0, 0xe9e3d441, 0x5, 0x24b246ed}}}}}
Fixes: 4ace11d ("bgpd: Move evpn_overlay to a pointer")
Tuetuopay
added a commit
to Tuetuopay/frr
that referenced
this pull request
Mar 18, 2025
With soft reconfiguration, the BGP attributes are interned, but the EVPN
attributes contained by the standard attributes are also interned.
However, during BGP route processing, we performed a copy of the
attributes in a new_attr struct, performing a shallow-copy. This made
two structs point to the same interned EVPN attributes, freeing the
attributes at the end of the input processing.
Fix the double-free by increasing the refcount when shallow-copying the
attributes.
The direct symptom can be seen with a topotest, where bgpd segfaults on
exit when cleaning up peer data:
(gdb) bt
FRRouting#12 0x00007fc57d6a8ff5 in malloc_printerr (str=str@entry=0x7fc57d7d18a0 "malloc_consolidate(): unaligned fastbin chunk detected") at ./malloc/malloc.c:5772
FRRouting#13 0x00007fc57d6a9d4c in malloc_consolidate (av=0x7fc57d803ac0 <main_arena>) at ./malloc/malloc.c:4846
FRRouting#14 0x00007fc57d6aada5 in _int_free_maybe_consolidate (av=0x7fc57d803ac0 <main_arena>, size=<optimized out>) at ./malloc/malloc.c:4779
FRRouting#15 0x00007fc57d6ab43a in _int_free (av=0x7fc57d803ac0 <main_arena>, p=<optimized out>, have_lock=<optimized out>) at ./malloc/malloc.c:4646
FRRouting#16 0x00007fc57d6addae in __GI___libc_free (mem=0x55704295e8a0) at ./malloc/malloc.c:3398
FRRouting#17 0x00007fc57dada55e in qfree (mt=mt@entry=0x7fc57dc34e60 <MTYPE_STREAM>, ptr=<optimized out>) at lib/memory.c:131
FRRouting#18 0x00007fc57db1b8f8 in stream_free (s=<optimized out>) at lib/stream.c:109
FRRouting#19 0x000055704186539e in sync_delete (subgrp=0x557042957f00) at bgpd/bgp_updgrp.c:108
FRRouting#20 update_subgroup_delete (subgrp=0x557042957f00) at bgpd/bgp_updgrp.c:1167
FRRouting#21 0x0000557041866c75 in update_subgroup_check_delete (subgrp=<optimized out>) at bgpd/bgp_updgrp.c:1202
FRRouting#22 0x00005570417fbf51 in update_group_remove_peer_afs (peer=<optimized out>) at ./bgpd/bgp_updgrp.h:523
FRRouting#23 bgp_stop (connection=<optimized out>) at bgpd/bgp_fsm.c:1478
FRRouting#24 0x0000557041800357 in bgp_event_update (connection=0x557042956b50, event=TCP_connection_closed) at bgpd/bgp_fsm.c:2655
FRRouting#25 0x00007fc57db28fae in event_call (thread=thread@entry=0x7ffe0c687760) at lib/event.c:2019
FRRouting#26 0x00007fc57daccb28 in frr_run (master=0x5570421106e0) at lib/libfrr.c:1247
FRRouting#27 0x00005570417b1fd3 in main (argc=<optimized out>, argv=0x7ffe0c687a28) at bgpd/bgp_main.c:557
Situation is even worse in real-world case where the route actually
leaves to other peers, as the free'd memory will quickly get
reallocated, trampled over, and trigger an assert on IP type (same one
as the previous route-map patch):
(gdb) bt
FRRouting#4 0x00007570922b1569 in _zlog_assert_failed (xref=xref@entry=0x5e9e11716280 <_xref.1>, extra=extra@entry=0x0) at ../lib/zlog.c:767
FRRouting#5 0x00005e9e114f005e in ipaddr_cmp (b=<optimized out>, a=<optimized out>) at ../lib/ipaddr.h:153
FRRouting#6 bgp_route_evpn_same (e1=<optimized out>, e2=<optimized out>) at ../bgpd/bgp_attr_evpn.c:36
FRRouting#7 0x00005e9e114e854b in overlay_index_same (a2=0x7ffc880779b0, a1=0x5e9e3cd16670) at ../bgpd/bgp_attr.h:632
FRRouting#8 attrhash_cmp (p1=0x5e9e3cd16670, p2=0x7ffc880779b0) at ../bgpd/bgp_attr.c:921
FRRouting#9 0x000075709222bd93 in hash_get (hash=0x5e9e3d1a3d70, data=data@entry=0x7ffc880779b0, alloc_func=alloc_func@entry=0x5e9e114e78a0 <bgp_attr_hash_alloc>) at ../lib/hash.c:142
FRRouting#10 0x00005e9e114e89f4 in bgp_attr_intern (attr=attr@entry=0x7ffc880779b0) at ../bgpd/bgp_attr.c:1134
FRRouting#11 0x00005e9e11621443 in bgp_advertise_attr_intern (hash=0x5e9e3d45bdc0, attr=attr@entry=0x7ffc880779b0) at ../bgpd/bgp_advertise.c:106
FRRouting#12 0x00005e9e1159317d in bgp_adj_out_set_subgroup (dest=dest@entry=0x5e9e3d45ca50, subgrp=subgrp@entry=0x5e9e3d45bcc0, attr=attr@entry=0x7ffc880779b0, path=path@entry=0x5e9e3d465010) at ../bgpd/bgp_updgrp_adv.c:618
FRRouting#13 0x00005e9e115666f1 in subgroup_process_announce_selected (subgrp=subgrp@entry=0x5e9e3d45bcc0, selected=<optimized out>, dest=0x5e9e3d45ca50, afi=afi@entry=AFI_L2VPN, safi=safi@entry=SAFI_EVPN, addpath_tx_id=0) at ../bgpd/bgp_route.c:3362
FRRouting#14 0x00005e9e11592a1f in group_announce_route_walkcb (updgrp=<optimized out>, arg=<optimized out>) at ../bgpd/bgp_updgrp_adv.c:260
FRRouting#15 0x000075709222c21a in hash_walk (hash=0x5e9e3d4390e0, func=func@entry=0x5e9e1158e3e0 <update_group_walkcb>, arg=arg@entry=0x7ffc88077be0) at ../lib/hash.c:270
FRRouting#16 0x00005e9e11591c77 in update_group_af_walk (bgp=bgp@entry=0x5e9e3d426eb0, afi=<optimized out>, safi=<optimized out>, cb=cb@entry=0x5e9e11592960 <group_announce_route_walkcb>, ctx=ctx@entry=0x7ffc88077c70) at ../bgpd/bgp_updgrp.c:2074
FRRouting#17 0x00005e9e115943e9 in group_announce_route (bgp=bgp@entry=0x5e9e3d426eb0, afi=afi@entry=AFI_L2VPN, safi=safi@entry=SAFI_EVPN, dest=dest@entry=0x5e9e3d45ca50, pi=pi@entry=0x5e9e3d465010) at ../bgpd/bgp_updgrp_adv.c:1119
FRRouting#18 0x00005e9e11562789 in bgp_process_main_one (bgp=bgp@entry=0x5e9e3d426eb0, dest=dest@entry=0x5e9e3d45ca50, afi=AFI_L2VPN, safi=SAFI_EVPN) at ../bgpd/bgp_route.c:3889
FRRouting#19 0x00005e9e11563088 in bgp_process_wq (wq=<optimized out>, data=0x5e9e3d467310) at ../bgpd/bgp_route.c:4015
FRRouting#20 0x000075709229eaa3 in work_queue_run (thread=0x7ffc88077ec0) at ../lib/workqueue.c:282
FRRouting#21 0x0000757092291d71 in event_call (thread=thread@entry=0x7ffc88077ec0) at ../lib/event.c:1996
FRRouting#22 0x000075709223a590 in frr_run (master=0x5e9e3cce2f10) at ../lib/libfrr.c:1232
FRRouting#23 0x00005e9e114e488e in main (argc=<optimized out>, argv=0x7ffc88078178) at ../bgpd/bgp_main.c:555
Indeed, the prefixes are complete garbage:
(gdb) up
FRRouting#7 0x00005e9e114e854b in overlay_index_same (a2=0x7ffc880779b0, a1=0x5e9e3cd16670) at ../bgpd/bgp_attr.h:632
(gdb) p/x a2->evpn_overlay->gw_ip
$2 = {ipa_type = 0x20, ip = {addr = 0x0, addrbytes = {0x0, 0x0, 0x0, 0x0, 0x41, 0xd4, 0xe3,
0xe9, 0x5, 0x0, 0x0, 0x0, 0xed, 0x46, 0xb2, 0x24}, _v4_addr = {s_addr = 0x0},
_v6_addr = {__in6_u = {__u6_addr8 = {0x0, 0x0, 0x0, 0x0, 0x41, 0xd4, 0xe3, 0xe9, 0x5,
0x0, 0x0, 0x0, 0xed, 0x46, 0xb2, 0x24}, __u6_addr16 = {0x0, 0x0, 0xd441, 0xe9e3,
0x5, 0x0, 0x46ed, 0x24b2}, __u6_addr32 = {0x0, 0xe9e3d441, 0x5, 0x24b246ed}}}}}
Fixes: 4ace11d ("bgpd: Move evpn_overlay to a pointer")
Signed-off-by: Tuetuopay <tuetuopay@me.com>
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
and match on full protocol name in proto_redistnum()
Signed-off-by: Quentin Young qlyoung@cumulusnetworks.com
Fixes #9