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.

Sign up for GitHub

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

Jump to bottom

OSPFv6 summarization not working properly #3

Closed
donaldsharp opened this issue Dec 16, 2016 · 1 comment
Closed

OSPFv6 summarization not working properly #3

donaldsharp opened this issue Dec 16, 2016 · 1 comment
Milestone
2.0-rc1

Comments

@donaldsharp
Copy link
Member

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

    Area Scoped Link State Database (Area 0.0.0.1)

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

    I/F Scoped Link State Database (I/F swp1 in Area 0.0.0.1)

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

    I/F Scoped Link State Database (I/F swp2 in Area 0.0.0.1)

Type LSId AdvRouter Age SeqNum Payload
Lnk 0.0.0.4 0.0.0.7 1034 80000003 fe80::202:ff:fe00:b

    AS Scoped Link State Database

Type LSId AdvRouter Age SeqNum Payload
@donaldsharp donaldsharp mentioned this issue Dec 16, 2016
Closed
@eqvinox eqvinox added this to the 2.0-rc1 milestone Dec 16, 2016
@donaldsharp donaldsharp mentioned this issue Jan 3, 2017
Merged
@eqvinox
Copy link
Contributor

eqvinox commented Jan 13, 2017

fix merged in #38

@eqvinox eqvinox closed this as completed Jan 13, 2017
@jannooo jannooo mentioned this issue Apr 18, 2017
Closed
@donaldsharp donaldsharp mentioned this issue Apr 19, 2017
Merged
Closed
@pguibert6WIND pguibert6WIND mentioned this issue Jul 17, 2017
Closed
donaldsharp pushed a commit that referenced this issue Aug 21, 2017
@mwinter-osr
Merge pull request #3 from silasm/Debian-Pkg-2.0
7bc07a7 
Debian pkg 2.0
This was referenced Sep 5, 2017
Closed
Closed
qlyoung referenced this issue in qlyoung/frr Sep 15, 2017
Merge pull request #3 in FRR/frr from master-frr-upstream-sync-2017-0…
c5f1582 
…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
  ...
@louberger louberger mentioned this issue Dec 13, 2017
Merged
@donaldsharp donaldsharp mentioned this issue Jan 11, 2018
Merged
@louberger louberger mentioned this issue Jan 24, 2018
Merged
dslicenc pushed a commit to dslicenc/frr that referenced this issue Feb 5, 2018
@donaldsharp
Merge pull request FRRouting#3 from vivek-cumulus/PBRD
eece9b7 
*: PBR - netlink interaction and basic definitions
@louberger louberger mentioned this issue Apr 3, 2018
Merged
This was referenced May 14, 2018
Closed
Closed
Closed
@mdtancsa mdtancsa mentioned this issue May 31, 2018
Closed
@donaldsharp donaldsharp mentioned this issue Jun 13, 2018
Closed
@nuqleo nuqleo mentioned this issue Jun 16, 2018
Closed
chiragshah6 pushed a commit to chiragshah6/frr that referenced this issue Jun 19, 2018
@qlyoung
Merge pull request FRRouting#3 from donaldsharp/more_error_stuff
e5beeb8 
More error stuff
@rwestphal rwestphal mentioned this issue Jul 9, 2018
Merged
@louberger louberger mentioned this issue Jul 11, 2018
Closed
@louberger louberger mentioned this issue Aug 27, 2018
Merged
@srimohans srimohans mentioned this issue Sep 11, 2018
Closed
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 19, 2024
@pguibert6WIND
bgpd: bmp, fix address sanitizer issue
7599d89 
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 19, 2024
@pguibert6WIND
bgpd: fix memory leak when updating peer up loc rib events
1f68f76 
The following memory leak can be observed when turning off and on the
BGP vrf interface.

> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 19, 2024
@pguibert6WIND
bgpd: bmp, fix memory leak in peer messages
a238cbe 
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 19, 2024
@pguibert6WIND
bgpd: fix access to invalid memory zone
e8ac410 
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 20, 2024
@pguibert6WIND
bgpd: bmp, fix address sanitizer issue
14ea03c 
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 20, 2024
@pguibert6WIND
bgpd: fix memory leak when updating peer up loc rib events
e6d5a04 
The following memory leak can be observed when turning off and on the
BGP vrf interface.

> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 20, 2024
@pguibert6WIND
bgpd: bmp, fix memory leak in peer messages
af4df14 
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 20, 2024
@pguibert6WIND
bgpd: fix access to invalid memory zone
fea295b 
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: bmp, fix address sanitizer issue
f8ca29a 
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: fix memory leak when updating peer up loc rib events
3c695c1 
The following memory leak can be observed when turning off and on the
BGP vrf interface.

> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: bmp, fix memory leak in peer messages
c716d01 
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: fix access to invalid memory zone
a41673d 
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: bmp, fix address sanitizer issue
0e1f0d2 
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: bmp, fix address sanitizer issue
9e940d4 
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: fix memory leak when updating peer up loc rib events
92f9848 
The following memory leak can be observed when turning off and on the
BGP vrf interface.

> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: bmp, fix memory leak in peer messages
8848f88 
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 30, 2024
@pguibert6WIND
bgpd: fix access to invalid memory zone
41a1911 
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Dec 31, 2024
@pguibert6WIND
bgpd: fix duplicate BGP instance created with unified config
e35e056 
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, 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 Dec 31, 2024
@pguibert6WIND
bgpd: fix bgp evpn memory leaks when adj-rib-in is disabled
9f7b3a2 
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 2, 2025
@pguibert6WIND
bgpd: fix duplicate BGP instance created with unified config
4100fe5 
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 2, 2025
@pguibert6WIND
bgpd: fix bgp evpn memory leaks when adj-rib-in is disabled
3ad2665 
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 2, 2025
@pguibert6WIND
bgpd: fix duplicate BGP instance created with unified config
6f3f017 
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 2, 2025
@pguibert6WIND
bgpd: fix bgp evpn memory leaks when adj-rib-in is disabled
a9b554f 
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 3, 2025
@pguibert6WIND
bgpd: fix duplicate BGP instance created with unified config
c7799e4 
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 3, 2025
@pguibert6WIND
bgpd: fix bgp evpn memory leaks when adj-rib-in is disabled
6ef780c 
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 7, 2025
@pguibert6WIND
bgpd: fix duplicate BGP instance created with unified config
3b351fb 
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 7, 2025
@pguibert6WIND
bgpd: fix bgp evpn memory leaks when adj-rib-in is disabled
8ef1ca1 
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 7, 2025
@pguibert6WIND
bgpd: bmp, fix memory leak in peer messages
3e63abf 
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Jan 7, 2025
@pguibert6WIND
bgpd: fix access to invalid memory zone
3e05ba0 
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND added a commit to pguibert6WIND/frr that referenced this issue Jan 7, 2025
@pguibert6WIND
zebra: prevent from creating pic nhe resolving over themselves
1b870c2 
There is no control on the returned nexthop group entry, when
finding pic contexts. Actually the pic context can resolve
over itself, and this may lead to stack overflow:

The below can be found by generalizing the search of pic nhe
for all nexthops and not only for srv6 contexts.

> root@ubuntu2204hwe:~/frr# AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==247856==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe4e6dcff8 (pc 0x561e05bb5653 bp 0x7ffe4e6dd020 sp 0x7ffe4e6dd000 T0)
>     #0 0x561e05bb5653 in zebra_nhg_install_kernel zebra/zebra_nhg.c:3310
>     FRRouting#1 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#2 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#3 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#4 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#5 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#6 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#7 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#8 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#9 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#10 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#11 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#12 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#13 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329
>     FRRouting#14 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329

Fix this by not returning a nexthop group entry when creation is
necessary for pic context.
Add a check when the pic creation is not needed and the returned
nhe has the same identifier as the requested nhe.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
2.0-rc1
Development

No branches or pull requests
2 participants
@eqvinox @donaldsharp