David Lamparter [Tue, 29 Nov 2022 11:09:45 +0000 (12:09 +0100)]
lib: add common NHT update decode callback
All users of `ZEBRA_NEXTHOP_UPDATE` check the VRF and then call into
`zapi_nexthop_update_decode` before further processing. Begin moving
this into common code in lib/.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Direct leak of 40 byte(s) in 10 object(s) allocated from:
#0 0x7f1cde6a9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x562b8eff328d in babel_interface_address_add babeld/babel_interface.c:112
#2 0x7f1cde1772cb in zclient_read lib/zclient.c:4425
#3 0x7f1cde14729c in event_call lib/event.c:1980
#4 0x7f1cde08a3bf in frr_run lib/libfrr.c:1214
#5 0x562b8eff481b in main babeld/babel_main.c:202
#6 0x7f1cdd8acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 40 byte(s) leaked in 10 allocation(s).
***********************************************************************************
```
Keelan10 [Wed, 15 Nov 2023 08:53:54 +0000 (12:53 +0400)]
babeld: Free IPv4 Memory in interface_reset
Release memory allocated for the IPv4 address during the interface reset.
The addition of `free(babel_ifp->ipv4)` ensures proper cleanup, preventing
potential memory leaks.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in babel_topo1.test_babel_topo1/r2.asan.babeld.18864
Direct leak of 8 byte(s) in 2 object(s) allocated from:
#0 0x7f3f4531bb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x55c1806cb28d in babel_interface_address_add babeld/babel_interface.c:112
#2 0x7f3f44de9e29 in zclient_read lib/zclient.c:4425
#3 0x7f3f44db9dfa in event_call lib/event.c:1965
#4 0x7f3f44cfd3bf in frr_run lib/libfrr.c:1214
#5 0x55c1806cc81b in main babeld/babel_main.c:202
#6 0x7f3f4451fc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Keelan10 [Wed, 15 Nov 2023 07:50:09 +0000 (11:50 +0400)]
sharpd: Set Callback Function for Memory Cleanup
Implement a callback function for memory cleanup of sharp_nh_tracker.
Specifically, set `sharp_nh_tracker_free` as the deletion function for the `sg.nhs` list.
This ensures proper cleanup of resources when elements are removed.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in zebra_nht_resolution.test_verify_nh_resolution/r1.asan.sharpd.32320
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f4ee812ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4ee7b291cc in qcalloc lib/memory.c:105
#2 0x5582be672011 in sharp_nh_tracker_get sharpd/sharp_nht.c:36
#3 0x5582be680b42 in watch_nexthop_v4_magic sharpd/sharp_vty.c:139
#4 0x5582be680b42 in watch_nexthop_v4 sharpd/sharp_vty_clippy.c:192
#5 0x7f4ee7aac0b1 in cmd_execute_command_real lib/command.c:978
#6 0x7f4ee7aac575 in cmd_execute_command lib/command.c:1036
#7 0x7f4ee7aac9f4 in cmd_execute lib/command.c:1203
#8 0x7f4ee7bd50bb in vty_command lib/vty.c:594
#9 0x7f4ee7bd5566 in vty_execute lib/vty.c:1357
#10 0x7f4ee7bdde37 in vtysh_read lib/vty.c:2365
#11 0x7f4ee7bc8dfa in event_call lib/event.c:1965
#12 0x7f4ee7b0c3bf in frr_run lib/libfrr.c:1214
#13 0x5582be671252 in main sharpd/sharp_main.c:188
#14 0x7f4ee6f1bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
Keelan10 [Tue, 14 Nov 2023 21:57:04 +0000 (01:57 +0400)]
zebra: Refactor memory allocation in zebra_rnh.c
Fix memory leaks by allocating `json_segs` conditionally on `nexthop->nh_srv6->seg6_segs`.
The previous code allocated memory even when not in use or attached to the JSON tree.
The ASan leak log for reference:
```
Direct leak of 3240 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de9e6f in json_object_new_array (/lib/x86_64-linux-gnu/libjson-c.so.3+0x3e6f)
#2 0x564dcab5c1a6 in vty_show_ip_route zebra/zebra_vty.c:705
#3 0x564dcab5cc71 in do_show_route_helper zebra/zebra_vty.c:955
#4 0x564dcab5d418 in do_show_ip_route zebra/zebra_vty.c:1039
#5 0x564dcab63ee5 in show_route_magic zebra/zebra_vty.c:1878
#6 0x564dcab63ee5 in show_route zebra/zebra_vty_clippy.c:659
#7 0x7f6e843b6fb1 in cmd_execute_command_real lib/command.c:978
#8 0x7f6e843b7475 in cmd_execute_command lib/command.c:1036
#9 0x7f6e843b78f4 in cmd_execute lib/command.c:1203
#10 0x7f6e844dfe3b in vty_command lib/vty.c:594
#11 0x7f6e844e02e6 in vty_execute lib/vty.c:1357
#12 0x7f6e844e8bb7 in vtysh_read lib/vty.c:2365
#13 0x7f6e844d3b7a in event_call lib/event.c:1965
#14 0x7f6e844172b0 in frr_run lib/libfrr.c:1214
#15 0x564dcaa50e81 in main zebra/main.c:488
#16 0x7f6e837f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 11520 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de88c0 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x28c0)
Indirect leak of 1080 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de8897 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x2897)
```
Donald Sharp [Tue, 14 Nov 2023 16:00:54 +0000 (11:00 -0500)]
lib: Prevent infinite loop in ospf
For some series of calls in FREEBSD setting the SO_RCVBUF size will
always fail under freebsd. This is no bueno since the
setsockopt_so_recvbuf call goes into an infinite loop.
(gdb) bt
0 setsockopt () at setsockopt.S:4
1 0x0000000083065870 in setsockopt_so_recvbuf (sock=15, size=0) at lib/sockopt.c:26
2 0x00000000002bd200 in ospf_ifp_sock_init (ifp=<optimized out>, ifp@entry=0x8d1dd500) at ospfd/ospf_network.c:290
3 0x00000000002ad1e0 in ospf_if_new (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x8eecf1c0) at ospfd/ospf_interface.c:276
4 0x0000000000304ee0 in add_ospf_interface (co=0x8eecbe10, area=0x8d192100) at ospfd/ospfd.c:1115
5 0x00000000003050fc in ospf_network_run_interface (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x80ff63f8, given_area=0x8d192100)
at ospfd/ospfd.c:1460
6 ospf_network_run (p=0x80ff63f8, area=0x8d192100) at ospfd/ospfd.c:1474
7 ospf_network_set (ospf=ospf@entry=0x8eefc000, p=p@entry=0x80ff63f8, area_id=..., df=<optimized out>) at ospfd/ospfd.c:1247
8 0x00000000002e876c in ospf_network_area (self=<optimized out>, vty=0x8eef3180, argc=<optimized out>, argv=<optimized out>)
at ospfd/ospf_vty.c:560
9 0x0000000083006f24 in cmd_execute_command_real (vline=vline@entry=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=<optimized out>,
cmd@entry=0x0, up_level=<optimized out>) at lib/command.c:978
10 0x0000000083006b30 in cmd_execute_command (vline=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0)
at lib/command.c:1037
11 0x0000000083007044 in cmd_execute (vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0",
matched=0x0, vtysh=0) at lib/command.c:1203
12 0x000000008307e9cc in vty_command (vty=0x8eef3180, buf=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0") at lib/vty.c:594
13 vty_execute (vty=vty@entry=0x8eef3180) at lib/vty.c:1357
14 0x000000008307ce40 in vtysh_read (thread=<optimized out>) at lib/vty.c:2365
15 0x0000000083073db0 in event_call (thread=thread@entry=0x80ff88a0) at lib/event.c:1965
16 0x000000008302c604 in frr_run (master=0x8d188140) at lib/libfrr.c:1214
17 0x000000000029c330 in main (argc=6, argv=<optimized out>) at ospfd/ospf_main.c:252
(gdb)
Force the setsockopt function to quit when the value we are passing no
longer makes any sense.
Fixes: #14790 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
========================
Mentioning few of the leaks here:
=3843268== 6 bytes in 3 blocks are still reachable in loss record 1 of 29
==3843268== at 0x483C855: malloc (vg_replace_malloc.c:381)
==3843268== by 0x489ED0E: qmalloc (memory.c:106)
==3843268== by 0x48DE8DB: redist_add_instance (zclient.c:125)
==3843268== by 0x48DF561: zclient_init (zclient.c:647)
==3843268== by 0x14FFA3: pim_zebra_init (pim_zebra.c:527)
==3843268== by 0x11D021: main (pim6_main.c:178)
==3843268==
==3843268== 24 bytes in 1 blocks are still reachable in loss record 2 of 29
==3843268== at 0x484147B: calloc (vg_replace_malloc.c:1328)
==3843268== by 0x489EE03: qcalloc (memory.c:111)
==3843268== by 0x4878DDE: buffer_new (buffer.c:72)
==3843268== by 0x48DE7BF: zclient_new (zclient.c:75)
==3843268== by 0x14FF1D: pim_zebra_init (pim_zebra.c:516)
==3843268== by 0x11D021: main (pim6_main.c:178)
==3843268==
==3843268== 24 bytes in 1 blocks are still reachable in loss record 3 of 29
==3843268== at 0x484147B: calloc (vg_replace_malloc.c:1328)
==3843268== by 0x489EE03: qcalloc (memory.c:111)
==3843268== by 0x4878DDE: buffer_new (buffer.c:72)
==3843268== by 0x48DE7BF: zclient_new (zclient.c:75)
==3843268== by 0x150A3D: zclient_lookup_new (pim_zlookup.c:131)
==3843268== by 0x11D021: main (pim6_main.c:178)
RCA:
=======================
Memory is allocated when the daemon started but
it is not freed when terminated.
Fix:
=======================
Freeing the memory when daemon goes down.
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).
Donald Sharp [Mon, 13 Nov 2023 15:26:48 +0000 (10:26 -0500)]
bgpd: Used %pBD instead of %pRN
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.
Igor Ryzhov [Sat, 11 Nov 2023 00:13:17 +0000 (02:13 +0200)]
lib, mgmtd: respect base xpath in mgmtd
`nb_cli_apply_changes` can be called with base xpath which should be
prepended to xpaths of every change in a transaction. This base xpath is
respected by regular northbound CLI but not by mgmtd. This commit fixes
the problem.
Igor Ryzhov [Fri, 20 Oct 2023 21:51:01 +0000 (00:51 +0300)]
mgmtd, lib: remove batch ids from all messages
Batch IDs are only used to verify that all messages were received and
processed by a backend. It's not necessary to do that as we use reliable
stream transport - messages can't be dropped or received out of order.
This commit also fixes possible race condition that can happen if
one backend process messages slower than other backends.
Igor Ryzhov [Sun, 12 Nov 2023 00:57:25 +0000 (02:57 +0200)]
bgpd: fix build error
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));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Christian Hopps [Sat, 11 Nov 2023 19:56:26 +0000 (20:56 +0100)]
tools: suppress some reachable external lib "leaks"
- These are just normal reachable allocs from inside external library code;
however, when running valgrind with memleak types "all" in order to find FRR
specific leaks (from memory.h) these are the only other reported leaks. Makes
easier checking and fixing.
Christian Hopps [Sat, 11 Nov 2023 18:21:17 +0000 (19:21 +0100)]
lib: mgmtd: fix debug cli commands and memleaks
- Cannot have 2 cmd_node's with same .node number. Install the mgmtd
client library debug nodes (client frontend and client backend) using
new unique node numbers. Fixes memleaks.
- Fix "debug mgmt client backend" to generate correct config (and not
for frontend).
Igor Ryzhov [Sat, 11 Nov 2023 00:06:11 +0000 (02:06 +0200)]
lib: fix possible freeing of libyang data
mgmtd frees all non-NULL change->value variables at the end of every
commit. We shouldn't assign change->value with data returned by libyang
to prevent freeing of library-allocated memory.
Donald Sharp [Thu, 2 Nov 2023 20:46:27 +0000 (16:46 -0400)]
lib: Modify event system to treat fd access more fairly
Keep track of the last starting spot of where fd's were
being handled for read operations. Modify the io read
handler to cycle through the list of fd's that need
to be handled such that fd's at the front do not take
precedence for being handled all the time.
Donald Sharp [Thu, 2 Nov 2023 16:02:43 +0000 (12:02 -0400)]
lib: Create a helper function for io read operations
Currently when io is ready inside of the event system
the first FD received is always preferred as the ones
that are handled first. This leads to results where
events associated with these first FD's are always handled
first.
In anticipation of a change to make this more fair
let's abstract the function handler.
The walk stopped because the index used in the NlriTable entries is
decrementing, and this is against the snmp specifications. Also, the
computed index is wrong, and does not match the provided
draft-ietf-idr-bgp4-mibv2-1 specification.
Fix this by computing a valid index, and by finding out the next
consecutive prefix.
The resulting changes do not break the walk, and the output is changed:
tests: Check received prefixes before immediately sending dynamic capabilities
If we send capabilities immediately, before receiving an UPDATE message, we end up
with a notification received from the neighbor. Let's wait until we have the fully
converged topology and do the stuff.
Tested locally and can't replicate the failure, let's see how happy is the CI this time.
bgpd: Send software version capability for OAD EBGP peers
We send this capability for iBGP peers by default. Recently OAD support was
merged, and we should adopt sending the capability according to OAD as well.
Donald Sharp [Sat, 4 Nov 2023 08:15:54 +0000 (08:15 +0000)]
*: Remove netlink headers from lib/zebra.h
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Christian Hopps [Tue, 24 Oct 2023 18:58:11 +0000 (14:58 -0400)]
tools: checkpatch updated with darr_foreach iter macros
Also update `checkpatch.sh` so it runs `checkpatch.pl` from the same directory
it resides in. This allows copying them both somewhere else to use a specific
version.
Donald Sharp [Mon, 6 Nov 2023 13:56:50 +0000 (08:56 -0500)]
zebra: When using Nexthop groups, use v6 RR semantics
The nexthop group route replace operation was made consistent
across all versions of the kernel. A v6 route replacement
does not need to do a delete than add when using nexthop
groups
Donald Sharp [Fri, 3 Nov 2023 16:35:45 +0000 (16:35 +0000)]
zebra: Add v6_rr_semantics status to `show zebra`
The v6_rr_semantics variable was being set but never
reported and had to be inferred from watching netlink
messages to the kernel. Let's add a bit of code
to `show zebra` so that we can know how it is being
used.
projects / mirror / frr.git / log