Skip to content
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

bgpd: Fix 'show ip bgp summary' variable output being wrong #8

Merged
merged 1 commit into from
Dec 20, 2016

Conversation

donaldsharp
Copy link
Member

The first time through calling 'show ip bgp summary'
we were always calculating the variable hostname field
size incorrectly.

Ticket: CM-13900
Signed-off-by: Donald Sharp [email protected]

The first time through calling 'show ip bgp summary'
we were always calculating the variable hostname field
size incorrectly.

Ticket: CM-13900
Signed-off-by: Donald Sharp <[email protected]>
@donaldsharp donaldsharp requested a review from eqvinox December 16, 2016 20:54
@eqvinox eqvinox merged commit 2504fdc into FRRouting:stable/2.0 Dec 20, 2016
@donaldsharp donaldsharp deleted the summary branch May 17, 2017 12:01
@louberger louberger mentioned this pull request Dec 13, 2017
cfra referenced this pull request in opensourcerouting/frr Nov 29, 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 <[email protected]>
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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 8, 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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 9, 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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 9, 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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 10, 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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 10, 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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Jan 13, 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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
@abdosi abdosi mentioned this pull request Jan 29, 2025
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Donatas Abraitis <[email protected]>
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 <[email protected]>
Signed-off-by: Donatas Abraitis <[email protected]>
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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Feb 13, 2025
…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 <[email protected]>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this pull request Feb 14, 2025
…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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants