OSPFv6 summarization not working properly #3
Milestone
Comments
Closed
|
fix merged in #38 |
Merged
This was referenced Sep 5, 2017
qlyoung
referenced
this issue
in qlyoung/frr
Sep 15, 2017
…7 to master * commit '95cc6152c70b56d783ce410c3a9e5a2d4b1d5a40': (271 commits) eigrpd, vtysh: add dummy route-map cli zebra: "debug zebra packet" config display lib: copy_nexthops() only copies the first nexthop pimd: fix merge damage in pim_show_nexthop() bgpd: fix sync damage in bgp_evpn_local_vni_add() Remove FRR-hacking.md documentation Add OSPF API and FRR Hacking documents ospf6d: crash in ospf6_lsdb_show bgpd: fix peer startup for labeled-unicast if linklocal address not found replace space to tabs, add kernel styles multiline, remove trailing whitespaces. Add note about bridge limitations whitespace internal 2 internal reindent vtysh: return non-zero for configuration failures pimd: do not call pim_bfd_write_config() with NULL ifp lib: route_node_lookup() needs to apply_mask() to prefix lib: route_node_lookup() needs to apply_mask() to prefix Add 1 more identation to correspond to kernel style multi-line comment ospf6d: crash in ospf6_lsdb_show bgpd: fix peer startup for labeled-unicast if linklocal address not found ...
Merged
dslicenc
pushed a commit
to dslicenc/frr
that referenced
this issue
Feb 5, 2018
*: PBR - netlink interaction and basic definitions
Merged
This was referenced May 14, 2018
chiragshah6
pushed a commit
to chiragshah6/frr
that referenced
this issue
Jun 19, 2018
More error stuff
Merged
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this issue
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 <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this issue
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 <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this issue
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 <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this issue
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 <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 > #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 issue
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 > #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>
cscarpitta
added a commit
to cscarpitta/frr
that referenced
this issue
Feb 2, 2025
When staticd receives a `ZAPI_SRV6_SID_RELEASED` notification from SRv6
SID Manager, it tries to unset the validity flag of `sid`. But since
the `sid` variable is NULL, we get a NULL pointer dereference.
```
=================================================================
==13815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000060 (pc 0xc14b813d9eac bp 0xffffcb135a40 sp 0xffffcb135a40 T0)
==13815==The signal is caused by a READ memory access.
==13815==Hint: address points to the zero page.
#0 0xc14b813d9eac in static_zebra_srv6_sid_notify staticd/static_zebra.c:1172
#1 0xe44e7aa2c194 in zclient_read lib/zclient.c:4746
FRRouting#2 0xe44e7a9b69d8 in event_call lib/event.c:1984
FRRouting#3 0xe44e7a85ac28 in frr_run lib/libfrr.c:1246
FRRouting#4 0xc14b813ccf98 in main staticd/static_main.c:193
FRRouting#5 0xe44e7a4773f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#6 0xe44e7a4774c8 in __libc_start_main_impl ../csu/libc-start.c:392
FRRouting#7 0xc14b813cc92c in _start (/usr/lib/frr/staticd+0x1c92c)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV staticd/static_zebra.c:1172 in static_zebra_srv6_sid_notify
==13815==ABORTING
```
This commit fixes the problem by doing a SID lookup first. If the SID
can't be found, we log an error and return. If the SID is found, we go
ahead and unset the validity flag.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
riw777
pushed a commit
that referenced
this issue
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 issue
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 issue
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>
routingrocks
added a commit
to routingrocks/frr
that referenced
this issue
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
routingrocks
added a commit
to routingrocks/frr
that referenced
this issue
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
mjstapp
pushed a commit
that referenced
this issue
Mar 11, 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 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #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 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #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 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #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 issue
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>
2 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem in this defect exhibited itself as a prefix that should be summarized by an area-range statement appearing the rib of a router downstream of the ABR, but not in the lsdb
r3# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, T - Table, v - VNC,
V - VPN,
> - selected route, * - FIB route
O>* 2000::/16 [110/30] via fe80::4638:39ff:fe00:6d99, swp1
O>* 2000:1000::/32 [110/30] via fe80::4638:39ff:fe00:6d99, swp1
O>* 2000:1000:1000:1000::/80 [110/20] via fe80::4638:39ff:fe00:6d99, swp1<<<<<<<<<<<<<<<<<<<<
O 3000:1000:1000:1000::/80 [110/10] is directly connected, swp1
C>* 3000:1000:1000:1000::/80 is directly connected, swp1
O>* 3000:1000:1000:1000:1::/80 [110/20] via fe80::4638:39ff:fe00:6d99, swp1
O 3000:1000:1000:1000:2::/80 [110/10] is directly connected, swp2
C>* 3000:1000:1000:1000:2::/80 is directly connected, swp2
O>* 4000:1000:1000:1000::/80 [110/40] via fe80::4638:39ff:fe00:6d99, swp1
C * fe80::/64 is directly connected, swp2
C * fe80::/64 is directly connected, swp1
C>* fe80::/64 is directly connected, eth0
Type LSId AdvRouter Age SeqNum Payload
Rtr 0.0.0.0 0.0.0.7 992 80000004 0.0.0.8/0.0.0.7
Rtr 0.0.0.0 0.0.0.8 993 80000004 0.0.0.8/0.0.0.7
Net 0.0.0.7 0.0.0.8 993 80000003 0.0.0.8
Net 0.0.0.7 0.0.0.8 993 80000003 0.0.0.7
IAP 0.0.0.0 0.0.0.8 987 80000003 2000::/16
IAP 0.0.0.1 0.0.0.8 987 80000005 2000:1000::/32
IAP 0.0.0.4 0.0.0.8 988 80000003 4000:1000:1000:1000::/80
INP 0.0.0.0 0.0.0.7 992 80000005 3000:1000:1000:1000:2::/80
INP 0.0.0.0 0.0.0.8 993 80000005 3000:1000:1000:1000:1::/80
INP 0.0.0.7 0.0.0.8 993 80000003 3000:1000:1000:1000::/80
Type LSId AdvRouter Age SeqNum Payload
Lnk 0.0.0.3 0.0.0.7 1034 80000003 fe80::202:ff:fe00:a
Lnk 0.0.0.7 0.0.0.8 1033 80000003 fe80::4638:39ff:fe00:6d99
Type LSId AdvRouter Age SeqNum Payload
Lnk 0.0.0.4 0.0.0.7 1034 80000003 fe80::202:ff:fe00:b
Type LSId AdvRouter Age SeqNum Payload
The text was updated successfully, but these errors were encountered: