```
Direct leak of 40 byte(s) in 1 object(s) allocated from:
0 0x7fc4b81eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7fc4b7bd60bb in qcalloc lib/memory.c:105
2 0x56221dc19207 in aspath_dup bgpd/bgp_aspath.c:689
3 0x56221daacd42 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
4 0x7fc4b7c3891a in route_map_apply_ext lib/routemap.c:2687
5 0x56221dace552 in subgroup_default_originate bgpd/bgp_updgrp_adv.c:906
6 0x56221dabf79c in update_group_default_originate_route_map_walkcb bgpd/bgp_updgrp.c:2105
7 0x56221dabde4e in update_group_walkcb bgpd/bgp_updgrp.c:1721
8 0x7fc4b7b9d398 in hash_walk lib/hash.c:270
9 0x56221dac94cb in update_group_af_walk bgpd/bgp_updgrp.c:2062
10 0x56221dac9b0f in update_group_walk bgpd/bgp_updgrp.c:2071
11 0x56221dac9fd5 in update_group_refresh_default_originate_route_map bgpd/bgp_updgrp.c:2118
12 0x7fc4b7c7fc54 in event_call lib/event.c:1974
13 0x7fc4b7bb9276 in frr_run lib/libfrr.c:1214
14 0x56221d9217fd in main bgpd/bgp_main.c:510
15 0x7fc4b6bf2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
tmp_pi.attr should be flushed since it's already interned (new_attr) or the
origin value is used (attr).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When filtering with `debug bgp updates in x.x.x.x prefix-list plist`, we want
to filter out unnecessary messages like:
```
127.0.0.1(Unknown) rcvd UPDATE wlen 0 attrlen 20 alen 5
```
Such a line as above will be repeated for all the paths received and it's useless
without knowing the prefix (because NLRIs are not parsed yet).
But want to see only relevant ones:
```
127.0.0.1(Unknown) rcvd UPDATE w/ attr: nexthop 127.0.0.1, origin i, path 65002
127.0.0.1(Unknown) rcvd 10.255.255.1/32 IPv4 unicast
```
With `debug bgp updates detail` we can combine this to something like:
```
127.0.0.1(Unknown) rcvd UPDATE w/ attr: nexthop 127.0.0.1, origin i, path 65002
127.0.0.1(Unknown) rcvd UPDATE wlen 0 attrlen 20 alen 5
127.0.0.1(Unknown) rcvd 10.255.255.1/32 IPv4 unicast
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are several problems with the bgp_sync_label_manager
function:
a) It is possible that a request in the lp->requests
fifo will be unable to be filled at this point in time
and the lf will be leaked and not ever fullfilled.
b) The bgp_sync_label_manager runs one time a second
irrelevant if there is work to do or not.
To fix (a) just add the request back to the requests
fifo and set the timer to pop in the future.
To fix (b) just every time something is put into
the request pool start a timer to run in 1 second
and do not restart it if all the work is done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This reverts commit 7bf3c2fb19.
Commit reverted as it introduces a memoery leak during the tests
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
The rfapi code was not using the zlog_backtrace()
functionality. Let's just convert over to using
the proper functionality that we have built in now.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix the following heap-buffer-overflow:
> ==3901635==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020003a5940 at pc 0x56260067bb48 bp 0x7ffe8a4f3840 sp 0x7ffe8a4f3838
> READ of size 4 at 0x6020003a5940 thread T0
> #0 0x56260067bb47 in ecommunity_fill_pbr_action bgpd/bgp_ecommunity.c:1587
> #1 0x5626007a246e in bgp_pbr_build_and_validate_entry bgpd/bgp_pbr.c:939
> #2 0x5626007b25e6 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2933
> #3 0x562600909d18 in bgp_zebra_announce bgpd/bgp_zebra.c:1351
> #4 0x5626007d5efd in bgp_process_main_one bgpd/bgp_route.c:3528
> #5 0x5626007d6b43 in bgp_process_wq bgpd/bgp_route.c:3641
> #6 0x7f450f34c2cc in work_queue_run lib/workqueue.c:266
> #7 0x7f450f327a27 in event_call lib/event.c:1970
> #8 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #9 0x56260062fc04 in main bgpd/bgp_main.c:540
> #10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
> #11 0x56260062ca29 in _start (/usr/lib/frr/bgpd+0x2e3a29)
>
> 0x6020003a5940 is located 0 bytes to the right of 16-byte region [0x6020003a5930,0x6020003a5940)
> allocated by thread T0 here:
> #0 0x7f450f6aa1f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> #1 0x7f450f244f8a in qrealloc lib/memory.c:112
> #2 0x562600673313 in ecommunity_add_val_internal bgpd/bgp_ecommunity.c:143
> #3 0x5626006735bc in ecommunity_uniq_sort_internal bgpd/bgp_ecommunity.c:193
> #4 0x5626006737e3 in ecommunity_parse_internal bgpd/bgp_ecommunity.c:228
> #5 0x562600673890 in ecommunity_parse bgpd/bgp_ecommunity.c:236
> #6 0x562600640469 in bgp_attr_ext_communities bgpd/bgp_attr.c:2674
> #7 0x562600646eb3 in bgp_attr_parse bgpd/bgp_attr.c:3893
> #8 0x562600791b7e in bgp_update_receive bgpd/bgp_packet.c:2141
> #9 0x56260079ba6b in bgp_process_packet bgpd/bgp_packet.c:3406
> #10 0x7f450f327a27 in event_call lib/event.c:1970
> #11 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #12 0x56260062fc04 in main bgpd/bgp_main.c:540
> #13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
Fixes: dacf6ec120 ("bgpd: utility routine to convert flowspec actions into pbr actions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When bgp update is received for EVPN prefix
where for an existing path's nexthop becomes unreachable,
the path is marked as not VALID but the routes
were not unimported from tenant vrfs, which lead to
stale unicast route(s) and nexthop(s).
In Multipath scenario only a specific path may have marked as
not VALID, then specific path info for the EVPN prefix required to be
unimported from tenant vrf.
Ticket: #3671288
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no function that both sets the nhg id, and sets
the ZAPI_MESSAGE_NHG flag if the nhg id is valid.
Create a ZAPI API to do this, and apply the changes wherever
needed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Separate the processing in bgp_zebra_announce(), by separating the
nexthop code in a separate function called
bgp_zebra_announce_parse_nexthop(). This commit does not bring any
functional change.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When adding/removing a route, the next-hop can be dumped
with debugging turned on. Move this function in a separate
function. There is no other change in this commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Send/Receive:
This field indicates whether the sender is (a) able to receive
multiple paths from its peer (value 1), (b) able to send
multiple paths to its peer (value 2), or (c) both (value 3) for
the <AFI, SAFI>.
If any other value is received, then the capability SHOULD be
treated as not understood and ignored [RFC5492].
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before:
```
ton# sh bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 0.0.0.2, local AS number 65001 VRF default vrf-id 0
```
After:
```
ton# sh bgp summary
IPv4 Unicast Summary:
BGP router identifier 0.0.0.2, local AS number 65001 VRF default vrf-id 0
```
After 5be4ee9634, we don't need to duplicate that
info.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The vrf name was not being displayed in this output.
New output:
eva# show bgp vrf all ipv4 uni summ
BGP router identifier 0.0.0.0, local AS number 99 VRF RED vrf-id 14
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 0.0.0.0, local AS number 99 VRF GREEN vrf-id 15
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 192.168.122.1, local AS number 99 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 0.0.0.0, local AS number 99 VRF GrEEn vrf-id -1
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Idle 0 N/A
Total number of neighbors 1
eva#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a peer has come up and already started installing
routes into the rib and `suppress-fib-pending` is either
turned on or off. BGP is left with some routes that
may need to be withdrawn from peers and routes that
it does not know the status of. Clear the BGP peers
for the interesting parties and let's let us come
up to speed as needed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is important especially for OPEN messages. Without this, we can't send
software-version capability which relies on OAD too.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If OAD is not set or set at least for one peer in peer-group, then split, and
create a separate update-group for those peers.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When added OAD support, it's handy to know peer->sub_sort also when printing
update-group debug messages.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This rework separates l3nhg functionality from the nexthop
tracking code, by introducing two bgp_nhg.[ch] files. The
calling functions are renamed from bgp_l3nhg* to bgp_nhg*.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This was missed for peer-groups. Moved this default handling from peer_create()
to peer_new() which is also used by peer_group_get().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In some cases BGP can be monitoring the same prefix
in both the nexthop and import check tables. If this
is the case, when unregistering one bnc from one table
make sure we are not still registered in the other
Example of the problem:
r1(config-router)# address-family ipv4 uni
r1(config-router-af)# no network 192.168.100.41/32
r1(config-router-af)# exit
r1# show bgp import-check-table
Current BGP import check cache:
r1# show bgp nexthop
Current BGP nexthop cache:
192.168.100.41 valid [IGP metric 0], #paths 1, peer 192.168.100.41
if r1-eth0
Last update: Wed Dec 6 11:01:40 2023
BGP now believes it is only watching 192.168.100.41 in the nexthop
cache, but zebra doesn't have anything:
r1# show ip import-check
VRF default:
Resolve via default: on
r1# show ip nht
VRF default:
Resolve via default: on
So if anything happens to the route that is being matched for
192.168.100.41 bgp is no longer going to be notified about this.
The source of this problem is that zebra has dropped the two different
tables into 1 table, while bgp has 2 tables to track this. The solution
to this problem (other than the rewrite that is being done ) is to have
BGP have a bit of smarts about looking in both tables for the bnc and
if found in both don't send the delete of the prefix tracking to zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no support for dumping multiple paths for the same prefix.
The current implementation only takes the first available entry.
Fix this by walking over the list of available paths, ordered by peer.
The nlri index is set gradually for each path.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
This is already handled above, no need to do here, because we could have an
overrun situation where len > 64 and we do out-of-bound actions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks.
The list callback deletion functions have been set.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180
=================================================================
==4180==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 544 byte(s) in 2 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591
#3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712
#4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758
#5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849
#6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299
#7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704
#8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164
#9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#10 0x7f8d1713f034 in event_call lib/event.c:1974
#11 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#12 0x55d5db99d19d in main bgpd/bgp_main.c:510
#13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135
#3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144
#4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#5 0x7f8d1713f034 in event_call lib/event.c:1974
#6 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#7 0x55d5db99d19d in main bgpd/bgp_main.c:510
#8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Release memory associated with `bgp->confed_peers` in the `bgp_free`
function to ensure proper cleanup. This fix prevents memory leaks related
to `confed_peers`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_confederation_astype.test_bgp_confederation_astype/r2.asan.bgpd.15045
=================================================================
==15045==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f5666787b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f56661867c7 in qrealloc lib/memory.c:112
#2 0x55a3b4736a40 in bgp_confederation_peers_add bgpd/bgpd.c:681
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7f5666720538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x7f5666186898 in qstrdup lib/memory.c:117
#2 0x55a3b4736adb in bgp_confederation_peers_add bgpd/bgpd.c:687
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Avoids calling VRF/interface/... handlers in library code more than
once. It's kinda surprising that this hasn't been blowing up already
for the VNC code, luckily these handlers are (mostly?) idempotent.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... and use it instead of fiddling with the `.synchronous` field.
(Make it const while at it.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When bgp is shutting down, it calls bgp_fsm_change_status
on everything including a self peer, which goes through
and cleans the tables of the self peer data structures
as if it's a real peer. Add a bit of code to just
not do the work at all. This allows unlocks to flow
a bit further and for the self peer to be deleted
on shutdown.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The MTYPE_BGP memory type was being over used as
both the handler for the bgp instance itself as
well as memory associated with name strings.
Let's separate out the two.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A route-map can be programmed to remove the route-target which
has been set with 'rt vpn export' command, but fails to remove
it.
Fix this by applying the route-map, then considering the resulting
extended community-list.
Add some tests to catch this issue.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The prefixes unexportation triggers an attempt to create
the VPN prefix node if that prefix was not already present.
For instance, if a given prefix is not exported because of
a route-map filtering, the withdraw process will try to
create the node with the 'bgp_afi_node_get()' command.
Fix this by replacing this call by the 'bgp_safi_node_lookup()'
function.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When exporting BGP prefixes, it is necessary to configure
the route target extended communities with the following
command:
> rt vpn export <RouteTarget>
But the customer may need to configure the route-target to
apply to bgp updates, solely based on a route-map criterium.
by using the below route-map configured like that:
> route-map vpn export <routemapname>
Fix this by allowing to export bgp updates based on the
presence of route-targets on either route-map or vpn
configured rt. the exportation process is stopped
if no route target is available in the ecommunity list.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following route-map set rules events are destroyed with
the 'match_destroy' API whereas there is a 'set_destroy' API
available.
Fix this for the following set commands:
> set distance
> set extcommunity rt
> set extcommunity nt
> set extcommunity color
> set extcommunity soo
Fixes: 48cb7ea99d ("bgpd: North-bound implementation for bgp rmaps")
Fixes: c9a2561444 ("bgpd: Implement Node Target Extended Communities")
Fixes: b80ebc2d8c ("bgpd: add colored extended communities support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ
is the standard for interface name length on all platforms
that FRR currently compiles on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
To avoid USE:
```
==587645==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000074050 at pc 0x55b34337d96c bp 0x7ffda59bb4c0 sp 0x7ffda59bb4b0
READ of size 8 at 0x604000074050 thread T0
0 0x55b34337d96b in bgp_attr_flush bgpd/bgp_attr.c:1289
1 0x55b34368ef85 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:111
2 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
3 0x7f7d41cdf81c in event_call lib/event.c:1980
4 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
5 0x55b343371e22 in main bgpd/bgp_main.c:510
6 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
7 0x55b3433769fd in _start (/usr/lib/frr/bgpd+0x2e29fd)
0x604000074050 is located 0 bytes inside of 40-byte region [0x604000074050,0x604000074078)
freed by thread T0 here:
#0 0x7f7d4207540f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
1 0x55b343396afd in community_free bgpd/bgp_community.c:41
2 0x55b343396afd in community_free bgpd/bgp_community.c:28
3 0x55b343397373 in community_intern bgpd/bgp_community.c:458
4 0x55b34337bed4 in bgp_attr_intern bgpd/bgp_attr.c:967
5 0x55b34368165b in bgp_advertise_attr_intern bgpd/bgp_advertise.c:106
6 0x55b3435277d7 in bgp_adj_out_set_subgroup bgpd/bgp_updgrp_adv.c:587
7 0x55b34368f36b in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:125
8 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
9 0x7f7d41cdf81c in event_call lib/event.c:1980
10 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
11 0x55b343371e22 in main bgpd/bgp_main.c:510
12 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7f7d42075a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7f7d41c3c28e in qcalloc lib/memory.c:105
2 0x55b3433976e8 in community_dup bgpd/bgp_community.c:514
3 0x55b34350273a in route_set_community bgpd/bgp_routemap.c:2589
4 0x7f7d41c96c06 in route_map_apply_ext lib/routemap.c:2690
5 0x55b34368f2d8 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:107
6 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
7 0x7f7d41cdf81c in event_call lib/event.c:1980
8 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
9 0x55b343371e22 in main bgpd/bgp_main.c:510
10 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
```
And also a crash:
```
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
1 0x00007ff3b7048ce0 in core_handler (signo=6, siginfo=0x7ffc8cf724b0, context=<optimized out>)
at lib/sigevent.c:246
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
4 0x00007ff3b6bb8859 in __GI_abort () at abort.c:79
5 0x00007ff3b6c2326e in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7ff3b6d4d298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
6 0x00007ff3b6c2b2fc in malloc_printerr (
str=str@entry=0x7ff3b6d4f628 "double free or corruption (fasttop)") at malloc.c:5347
7 0x00007ff3b6c2cc65 in _int_free (av=0x7ff3b6d82b80 <main_arena>, p=0x555c8fa70a10, have_lock=0)
at malloc.c:4266
8 0x0000555c8da94bd3 in community_free (com=0x7ffc8cf72e70) at bgpd/bgp_community.c:41
9 community_free (com=com@entry=0x7ffc8cf72e70) at bgpd/bgp_community.c:28
10 0x0000555c8da8afc1 in bgp_attr_flush (attr=attr@entry=0x7ffc8cf73040) at bgpd/bgp_attr.c:1290
11 0x0000555c8dbc0760 in bgp_conditional_adv_routes (peer=peer@entry=0x555c8fa627c0,
afi=afi@entry=AFI_IP, safi=SAFI_UNICAST, table=table@entry=0x555c8fa510b0, rmap=0x555c8fa71cb0,
update_type=UPDATE_TYPE_ADVERTISE) at bgpd/bgp_conditional_adv.c:111
12 0x0000555c8dbc0b75 in bgp_conditional_adv_timer (t=<optimized out>)
at bgpd/bgp_conditional_adv.c:301
13 0x00007ff3b705b84c in event_call (thread=thread@entry=0x7ffc8cf73440) at lib/event.c:1980
14 0x00007ff3b700bf98 in frr_run (master=0x555c8f27c090) at lib/libfrr.c:1214
15 0x0000555c8da85f05 in main (argc=<optimized out>, argv=0x7ffc8cf736a8) at bgpd/bgp_main.c:510
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The function aspath_remove_private_asns was using an aspath to perform some operation and didnt free it after usage leading to the leak below.
***********************************************************************************
Address Sanitizer Error detected in bgp_remove_private_as_route_map.test_bgp_remove_private_as_route_map/r2.asan.bgpd.27074
=================================================================
==27074==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#10 0x7fd0a463322a in event_call lib/event.c:1970
#11 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#12 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#13 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#10 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#11 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#12 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#13 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#14 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#15 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#16 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#17 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#18 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#19 0x7fd0a463322a in event_call lib/event.c:1970
#20 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#21 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#22 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#12 0x7fd0a463322a in event_call lib/event.c:1970
#13 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#14 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#15 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#12 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#13 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#14 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#15 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#16 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#17 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#18 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#19 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#20 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#21 0x7fd0a463322a in event_call lib/event.c:1970
#22 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#23 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#24 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#13 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#14 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#15 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#16 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#17 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#18 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#19 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#20 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#21 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#22 0x7fd0a463322a in event_call lib/event.c:1970
#23 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#24 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#25 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#13 0x7fd0a463322a in event_call lib/event.c:1970
#14 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#15 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#16 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#14 0x7fd0a463322a in event_call lib/event.c:1970
#15 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#16 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#17 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#14 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#15 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#16 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#17 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#18 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#19 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#20 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#21 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#22 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#23 0x7fd0a463322a in event_call lib/event.c:1970
#24 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#25 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#26 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 416 byte(s) leaked in 16 allocation(s).
***********************************************************************************
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
CID 1570969 Overrun
/bgpd/bgp_snmp_bgp4v2.c: 534 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 575 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 514 in bgp4v2PathAttrLookup()
>>> CID 1570969: (OVERRUN)
>>> Overrunning array "bgp->rib" of 4 64-byte elements at element index 4 (byte offset 319) using index "afi" (which evaluates to 4).
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Let's use the natural data structure in bgp for the prefix display
instead of a bunch of places where we call a translator function.
The %pBD does this and actually ensures data is correct.
Also fix a few spots in bgp_zebra.c where the cast to a NULL
pointer causes the catcher functionality to not work and fix
the resulting crash that resulted.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I recieve the following error with GCC 9.4.0:
```
In file included from /usr/include/string.h:495,
from ./lib/zebra.h:23,
from bgpd/bgp_snmp_bgp4v2.c:7:
In function ‘memset’,
inlined from ‘bgp4v2PathAttrLookup’ at bgpd/bgp_snmp_bgp4v2.c:605:3,
inlined from ‘bgp4v2PathAttrTable’ at bgpd/bgp_snmp_bgp4v2.c:747:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10: error: ‘__builtin_memset’ offset [9, 20] from the object at ‘paddr’ is out of the bounds of referenced subobject ‘_v4_addr’ with type ‘struct in_addr’ at offset 4 [-Werror=array-bounds]
71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add guard for `zlog_debug` when bgpd is not connected to zebra
or zebra does not know the bgp instance.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
