forked from FRRouting/frr
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error reference cards #7
Merged
qlyoung
merged 6 commits into
qlyoung:error-reference-cards
from
donaldsharp:error-reference-cards
Jun 19, 2018
Merged
Error reference cards #7
qlyoung
merged 6 commits into
qlyoung:error-reference-cards
from
donaldsharp:error-reference-cards
Jun 19, 2018
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Feb 25, 2019
If path->net is NULL in the bgp_path_info_free() function, then bgpd would crash in bgp_addpath_free_info_data() with the following backtrace: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ff7b267a42a in __GI_abort () at abort.c:89 #2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249 #3 <signal handler called> #4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368 #5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100 #6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252 #7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276 #8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320 #9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476 FRRouting#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 FRRouting#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 FRRouting#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 FRRouting#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 FRRouting#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481 Add a null-check protection to fix this problem. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
qlyoung
pushed a commit
that referenced
this pull request
May 7, 2019
If path->net is NULL in the bgp_path_info_free() function, then bgpd would crash in bgp_addpath_free_info_data() with the following backtrace: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ff7b267a42a in __GI_abort () at abort.c:89 #2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249 #3 <signal handler called> #4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368 #5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100 #6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252 #7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276 #8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320 #9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476 FRRouting#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 FRRouting#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 FRRouting#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 FRRouting#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 FRRouting#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481 Add a null-check protection to fix this problem. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
qlyoung
pushed a commit
that referenced
this pull request
Aug 8, 2019
If path->net is NULL in the bgp_path_info_free() function, then bgpd would crash in bgp_addpath_free_info_data() with the following backtrace: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ff7b267a42a in __GI_abort () at abort.c:89 #2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249 #3 <signal handler called> #4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368 #5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100 #6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252 #7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276 #8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320 #9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476 FRRouting#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 FRRouting#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 FRRouting#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 FRRouting#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 FRRouting#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481 Add a null-check protection to fix this problem. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
qlyoung
pushed a commit
that referenced
this pull request
Oct 11, 2019
Our Address Sanitizer CI is finding this issue: error 09-Oct-2019 19:28:33 r4: bgpd triggered an exception by AddressSanitizer error 09-Oct-2019 19:28:33 ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540 error 09-Oct-2019 19:28:33 READ of size 1 at 0x7ffdd425b060 thread T0 error 09-Oct-2019 19:28:33 #0 0x68575e in prefix_cmp lib/prefix.c:776 error 09-Oct-2019 19:28:33 #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230 error 09-Oct-2019 19:28:33 #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520 error 09-Oct-2019 19:28:33 #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071 error 09-Oct-2019 19:28:33 #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736 error 09-Oct-2019 19:28:33 #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237 error 09-Oct-2019 19:28:33 #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315 error 09-Oct-2019 19:28:33 #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598 error 09-Oct-2019 19:28:33 #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274 error 09-Oct-2019 19:28:33 #9 0x6b9f54 in thread_call lib/thread.c:1531 error 09-Oct-2019 19:28:33 FRRouting#10 0x657037 in frr_run lib/libfrr.c:1052 error 09-Oct-2019 19:28:33 FRRouting#11 0x42d268 in main bgpd/bgp_main.c:486 error 09-Oct-2019 19:28:33 FRRouting#12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) error 09-Oct-2019 19:28:33 FRRouting#13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8) error 09-Oct-2019 19:28:33 error 09-Oct-2019 19:28:33 Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame error 09-Oct-2019 19:28:33 #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103 error 09-Oct-2019 19:28:33 error 09-Oct-2019 19:28:33 This frame has 5 object(s): error 09-Oct-2019 19:28:33 [32, 36) 'label' error 09-Oct-2019 19:28:33 [96, 108) 'rd_as' error 09-Oct-2019 19:28:33 [160, 172) 'rd_ip' error 09-Oct-2019 19:28:33 [224, 240) 'prd' <== Memory access at offset 240 overflows this variable error 09-Oct-2019 19:28:33 [288, 336) 'p' error 09-Oct-2019 19:28:33 HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext error 09-Oct-2019 19:28:33 (longjmp and C++ exceptions *are* supported) error 09-Oct-2019 19:28:33 SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp error 09-Oct-2019 19:28:33 Shadow bytes around the buggy address: error 09-Oct-2019 19:28:33 0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 error 09-Oct-2019 19:28:33 0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 error 09-Oct-2019 19:28:33 0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2 error 09-Oct-2019 19:28:33 =>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2 error 09-Oct-2019 19:28:33 0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00 error 09-Oct-2019 19:28:33 0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4 error 09-Oct-2019 19:28:33 0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00 error 09-Oct-2019 19:28:33 0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 error 09-Oct-2019 19:28:33 Shadow byte legend (one shadow byte represents 8 application bytes): error 09-Oct-2019 19:28:33 Addressable: 00 error 09-Oct-2019 19:28:33 Partially addressable: 01 02 03 04 05 06 07 error 09-Oct-2019 19:28:33 Heap left redzone: fa error 09-Oct-2019 19:28:33 Heap right redzone: fb error 09-Oct-2019 19:28:33 Freed heap region: fd error 09-Oct-2019 19:28:33 Stack left redzone: f1 error 09-Oct-2019 19:28:33 Stack mid redzone: f2 error 09-Oct-2019 19:28:33 Stack right redzone: f3 error 09-Oct-2019 19:28:33 Stack partial redzone: f4 error 09-Oct-2019 19:28:33 Stack after return: f5 error 09-Oct-2019 19:28:33 Stack use after scope: f8 error 09-Oct-2019 19:28:33 Global redzone: f9 error 09-Oct-2019 19:28:33 Global init order: f6 error 09-Oct-2019 19:28:33 Poisoned by user: f7 error 09-Oct-2019 19:28:33 Container overflow: fc error 09-Oct-2019 19:28:33 Array cookie: ac error 09-Oct-2019 19:28:33 Intra object redzone: bb error 09-Oct-2019 19:28:33 ASan internal: fe error 09-Oct-2019 19:28:36 r3: Daemon bgpd not running This is the result of this code pattern in rfapi/rfapi_import.c: prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd, (struct prefix *)prd)) Effectively prd or vnc.import.rd are `struct prefix_rd` which are being typecast to a `struct prefix`. Not a big deal except commit 1315d74 modified the prefix_cmp function to allow for a sorted prefix_cmp. In prefix_cmp we were looking at the offset and shift. In the case of vnc we were passing a prefix length of 64 which is the exact length of the remaining data structure for struct prefix_rd. So we calculated a offset of 8 and a shift of 0. The data structures for the prefix portion happened to be equal to 64 bits of data. So we checked that with the memcmp got a 0 and promptly read off the end of the data structure for the numcmp. The fix is if shift is 0 that means thei the memcmp has checked everything and there is nothing to do. Please note: We will still crash if we set the prefixlen > then ~312 bits currently( ie if the prefixlen specifies a bit length longer than the prefix length ). I do not think there is anything to do here( nor am I sure how to correct this either ) as that we are going to have some severe problems when we muck up the prefixlen. Fixes: FRRouting#5025 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 17, 2019
This code is called from the zebra main pthread during shutdown but the thread event is scheduled via the zebra dplane pthread. Hence, we should be using the `thread_cancel_async()` API to cancel the thread event on a different pthread. This is only ever hit in the rare case that we still have work left to do on the update queue during shutdown. Found via zebra crash: ``` (gdb) bt \#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 \#1 0x00007f4e4d3f7535 in __GI_abort () at abort.c:79 \#2 0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()", file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92 \#3 0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c", line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101 \#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 \#5 0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274 \#6 0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202 \#7 0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599 \#8 0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024 \#9 0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483 (gdb) down \#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 1185 assert(master->owner == pthread_self()); (gdb) ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Dec 22, 2019
Address Sanitizer is reporting this issue: ==26177==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120000238d8 at pc 0x7f88f7c4fa93 bp 0x7fff9a641830 sp 0x7fff9a641820 READ of size 8 at 0x6120000238d8 thread T0 #0 0x7f88f7c4fa92 in if_delete lib/if.c:290 #1 0x42192e in ospf_vl_if_delete ospfd/ospf_interface.c:912 #2 0x42192e in ospf_vl_delete ospfd/ospf_interface.c:990 #3 0x4a6208 in no_ospf_area_vlink ospfd/ospf_vty.c:1227 #4 0x7f88f7c1553d in cmd_execute_command_real lib/command.c:1073 #5 0x7f88f7c19b1e in cmd_execute_command lib/command.c:1132 #6 0x7f88f7c19e8e in cmd_execute lib/command.c:1288 #7 0x7f88f7cd7523 in vty_command lib/vty.c:516 #8 0x7f88f7cd79ff in vty_execute lib/vty.c:1285 #9 0x7f88f7cde4f9 in vtysh_read lib/vty.c:2119 FRRouting#10 0x7f88f7ccb845 in thread_call lib/thread.c:1549 FRRouting#11 0x7f88f7c5d6a7 in frr_run lib/libfrr.c:1093 FRRouting#12 0x412976 in main ospfd/ospf_main.c:221 FRRouting#13 0x7f88f73b082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) FRRouting#14 0x413c78 in _start (/usr/local/master/sbin/ospfd+0x413c78) Effectively we are in a shutdown phase and as part of shutdown we delete the ospf interface pointer ( ifp->info ). The interface deletion code was modified in the past year to pass in the address of operator to allow us to NULL out the holding pointer. The catch here is that we free the oi and then delete the interface passing in the address of the oi->ifp pointer, causing a use after free. Fixes: FRRouting#5555 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 2, 2020
We were not connecting the default zebra_ns to the default ns->info at namespace initialization in zebra. Thus, when we tried to use the `ns_walk_func()` it would ignore the default zebra_ns since there is no pointer to it from the ns struct. Fix this by connecting them in `zebra_ns_init()` and, if the default ns is not found, exit with failure since this is not recoverable. This was found during a crash where we fail to cancel the kernel_read thread at termination (via the `ns_walk_func()`) and then we get a netlink notification trying to use the zns struct that has already been freed. ``` (gdb) bt \#0 0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 \#1 0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 \#2 0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254 \#3 <signal handler called> \#4 0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269 \#5 0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043 \#6 0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384 \#7 0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940, count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932 \#8 0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406 \#9 0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599 \FRRouting#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024 \FRRouting#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483 ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 3, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 4, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 6, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 7, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 7, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 8, 2020
Running with --enable-address-sanitizer I am seeing this: ================================================================= ==19520==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ef850 at pc 0x7fe9b8f7b57b bp 0x7fffbac6f9c0 sp 0x7fffbac6f170 READ of size 6 at 0x6020003ef850 thread T0 #0 0x7fe9b8f7b57a (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x55e33d1071e5 in bgp_process_mac_rescan_table bgpd/bgp_mac.c:159 #2 0x55e33d107c09 in bgp_mac_rescan_evpn_table bgpd/bgp_mac.c:252 #3 0x55e33d107e39 in bgp_mac_rescan_all_evpn_tables bgpd/bgp_mac.c:266 #4 0x55e33d108270 in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:291 #5 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 #6 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 #7 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 #8 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 #9 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 FRRouting#10 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#11 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#12 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#13 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 FRRouting#14 0x55e33d09c189 in _start (/usr/lib/frr/bgpd+0x168189) 0x6020003ef850 is located 0 bytes inside of 16-byte region [0x6020003ef850,0x6020003ef860) freed by thread T0 here: #0 0x7fe9b8fabfb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0) #1 0x7fe9b8ce4ea9 in qfree lib/memory.c:129 #2 0x55e33d10825c in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:289 #3 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 #4 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 #5 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 #6 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 #7 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 #8 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 #9 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#10 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#11 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7fe9b8fac518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fe9b8ce4d93 in qcalloc lib/memory.c:110 #2 0x55e33d106b29 in bgp_mac_hash_alloc bgpd/bgp_mac.c:96 #3 0x7fe9b8cb8350 in hash_get lib/hash.c:149 #4 0x55e33d10845b in bgp_mac_add_mac_entry bgpd/bgp_mac.c:303 #5 0x55e33d226757 in bgp_ifp_create bgpd/bgp_zebra.c:2644 #6 0x7fe9b8cbf1e6 in if_new_via_zapi lib/if.c:176 #7 0x7fe9b8db2d3b in zclient_interface_add lib/zclient.c:1481 #8 0x7fe9b8db87f8 in zclient_read lib/zclient.c:2659 #9 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#10 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#11 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#12 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 Effectively we are passing to bgp_mac_remove_ifp_internal the macaddr that is associated with the bsm data structure. There exists a path where the bsm is freed and then we immediately pass the macaddr into bgp_mac_rescan_all_evpn_tables. So just make a copy of the macaddr data structure before we free the bsm Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 8, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 15, 2020
==25402==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x533302 in calloc (/usr/lib/frr/zebra+0x533302) #1 0x7fee84cdc80b in qcalloc /home/qlyoung/frr/lib/memory.c:110:27 #2 0x5a3032 in create_label_chunk /home/qlyoung/frr/zebra/label_manager.c:188:3 #3 0x5a3c2b in assign_label_chunk /home/qlyoung/frr/zebra/label_manager.c:354:8 #4 0x5a2a38 in label_manager_get_chunk /home/qlyoung/frr/zebra/label_manager.c:424:9 #5 0x5a1412 in hook_call_lm_get_chunk /home/qlyoung/frr/zebra/label_manager.c:60:1 #6 0x5a1412 in lm_get_chunk_call /home/qlyoung/frr/zebra/label_manager.c:81:2 #7 0x72a234 in zread_get_label_chunk /home/qlyoung/frr/zebra/zapi_msg.c:2026:2 #8 0x72a234 in zread_label_manager_request /home/qlyoung/frr/zebra/zapi_msg.c:2073:4 #9 0x73150c in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2688:2 When creating label chunk that has a specified base, we eventually are calling assign_specific_label_chunk. This function finds the appropriate list node and deletes it from the lbl_mgr.lc_list but since the function uses list_delete_node() the deletion function that is specified for lbl_mgr.lc_list is not called thus dropping the memory. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 15, 2020
Our Address Sanitizer CI is finding this issue: error 09-Oct-2019 19:28:33 r4: bgpd triggered an exception by AddressSanitizer error 09-Oct-2019 19:28:33 ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540 error 09-Oct-2019 19:28:33 READ of size 1 at 0x7ffdd425b060 thread T0 error 09-Oct-2019 19:28:33 #0 0x68575e in prefix_cmp lib/prefix.c:776 error 09-Oct-2019 19:28:33 #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230 error 09-Oct-2019 19:28:33 #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520 error 09-Oct-2019 19:28:33 #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071 error 09-Oct-2019 19:28:33 #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736 error 09-Oct-2019 19:28:33 #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237 error 09-Oct-2019 19:28:33 #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315 error 09-Oct-2019 19:28:33 #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598 error 09-Oct-2019 19:28:33 #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274 error 09-Oct-2019 19:28:33 #9 0x6b9f54 in thread_call lib/thread.c:1531 error 09-Oct-2019 19:28:33 FRRouting#10 0x657037 in frr_run lib/libfrr.c:1052 error 09-Oct-2019 19:28:33 FRRouting#11 0x42d268 in main bgpd/bgp_main.c:486 error 09-Oct-2019 19:28:33 FRRouting#12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) error 09-Oct-2019 19:28:33 FRRouting#13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8) error 09-Oct-2019 19:28:33 error 09-Oct-2019 19:28:33 Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame error 09-Oct-2019 19:28:33 #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103 error 09-Oct-2019 19:28:33 error 09-Oct-2019 19:28:33 This frame has 5 object(s): error 09-Oct-2019 19:28:33 [32, 36) 'label' error 09-Oct-2019 19:28:33 [96, 108) 'rd_as' error 09-Oct-2019 19:28:33 [160, 172) 'rd_ip' error 09-Oct-2019 19:28:33 [224, 240) 'prd' <== Memory access at offset 240 overflows this variable error 09-Oct-2019 19:28:33 [288, 336) 'p' error 09-Oct-2019 19:28:33 HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext error 09-Oct-2019 19:28:33 (longjmp and C++ exceptions *are* supported) error 09-Oct-2019 19:28:33 SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp error 09-Oct-2019 19:28:33 Shadow bytes around the buggy address: error 09-Oct-2019 19:28:33 0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 error 09-Oct-2019 19:28:33 0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 error 09-Oct-2019 19:28:33 0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2 error 09-Oct-2019 19:28:33 =>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2 error 09-Oct-2019 19:28:33 0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00 error 09-Oct-2019 19:28:33 0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 error 09-Oct-2019 19:28:33 0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4 error 09-Oct-2019 19:28:33 0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00 error 09-Oct-2019 19:28:33 0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 error 09-Oct-2019 19:28:33 Shadow byte legend (one shadow byte represents 8 application bytes): error 09-Oct-2019 19:28:33 Addressable: 00 error 09-Oct-2019 19:28:33 Partially addressable: 01 02 03 04 05 06 07 error 09-Oct-2019 19:28:33 Heap left redzone: fa error 09-Oct-2019 19:28:33 Heap right redzone: fb error 09-Oct-2019 19:28:33 Freed heap region: fd error 09-Oct-2019 19:28:33 Stack left redzone: f1 error 09-Oct-2019 19:28:33 Stack mid redzone: f2 error 09-Oct-2019 19:28:33 Stack right redzone: f3 error 09-Oct-2019 19:28:33 Stack partial redzone: f4 error 09-Oct-2019 19:28:33 Stack after return: f5 error 09-Oct-2019 19:28:33 Stack use after scope: f8 error 09-Oct-2019 19:28:33 Global redzone: f9 error 09-Oct-2019 19:28:33 Global init order: f6 error 09-Oct-2019 19:28:33 Poisoned by user: f7 error 09-Oct-2019 19:28:33 Container overflow: fc error 09-Oct-2019 19:28:33 Array cookie: ac error 09-Oct-2019 19:28:33 Intra object redzone: bb error 09-Oct-2019 19:28:33 ASan internal: fe error 09-Oct-2019 19:28:36 r3: Daemon bgpd not running This is the result of this code pattern in rfapi/rfapi_import.c: prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd, (struct prefix *)prd)) Effectively prd or vnc.import.rd are `struct prefix_rd` which are being typecast to a `struct prefix`. Not a big deal except commit 1315d74 modified the prefix_cmp function to allow for a sorted prefix_cmp. In prefix_cmp we were looking at the offset and shift. In the case of vnc we were passing a prefix length of 64 which is the exact length of the remaining data structure for struct prefix_rd. So we calculated a offset of 8 and a shift of 0. The data structures for the prefix portion happened to be equal to 64 bits of data. So we checked that with the memcmp got a 0 and promptly read off the end of the data structure for the numcmp. The fix is if shift is 0 that means thei the memcmp has checked everything and there is nothing to do. Please note: We will still crash if we set the prefixlen > then ~312 bits currently( ie if the prefixlen specifies a bit length longer than the prefix length ). I do not think there is anything to do here( nor am I sure how to correct this either ) as that we are going to have some severe problems when we muck up the prefixlen. Fixes: FRRouting#5025 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 16, 2020
==25402==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x533302 in calloc (/usr/lib/frr/zebra+0x533302) #1 0x7fee84cdc80b in qcalloc /home/qlyoung/frr/lib/memory.c:110:27 #2 0x5a3032 in create_label_chunk /home/qlyoung/frr/zebra/label_manager.c:188:3 #3 0x5a3c2b in assign_label_chunk /home/qlyoung/frr/zebra/label_manager.c:354:8 #4 0x5a2a38 in label_manager_get_chunk /home/qlyoung/frr/zebra/label_manager.c:424:9 #5 0x5a1412 in hook_call_lm_get_chunk /home/qlyoung/frr/zebra/label_manager.c:60:1 #6 0x5a1412 in lm_get_chunk_call /home/qlyoung/frr/zebra/label_manager.c:81:2 #7 0x72a234 in zread_get_label_chunk /home/qlyoung/frr/zebra/zapi_msg.c:2026:2 #8 0x72a234 in zread_label_manager_request /home/qlyoung/frr/zebra/zapi_msg.c:2073:4 #9 0x73150c in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2688:2 When creating label chunk that has a specified base, we eventually are calling assign_specific_label_chunk. This function finds the appropriate list node and deletes it from the lbl_mgr.lc_list but since the function uses list_delete_node() the deletion function that is specified for lbl_mgr.lc_list is not called thus dropping the memory. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Mar 18, 2020
Upper level clients ask for default routes of a particular family This change ensures that they only receive the family that they have asked for. Discovered when testing in ospf `default-information originate` ================================================================= ==246306==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffa2e8 at pc 0x7ffff73c44e2 bp 0x7fffffffa090 sp 0x7fffffffa088 READ of size 16 at 0x7fffffffa2e8 thread T0 #0 0x7ffff73c44e1 in prefix_copy lib/prefix.c:310 #1 0x7ffff741c0aa in route_node_lookup lib/table.c:255 #2 0x5555556cd263 in ospf_external_info_delete ospfd/ospf_asbr.c:178 #3 0x5555556a47cc in ospf_zebra_read_route ospfd/ospf_zebra.c:852 #4 0x7ffff746f5d8 in zclient_read lib/zclient.c:3028 #5 0x7ffff742fc91 in thread_call lib/thread.c:1549 #6 0x7ffff7374642 in frr_run lib/libfrr.c:1093 #7 0x5555555bfaef in main ospfd/ospf_main.c:235 #8 0x7ffff70a2bba in __libc_start_main ../csu/libc-start.c:308 #9 0x5555555bf499 in _start (/usr/lib/frr/ospfd+0x6b499) Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Apr 5, 2020
Implement tests to verify BGP link-bandwidth and weighted ECMP functionality. These tests validate one of the primary use cases for weighted ECMP (a.k.a. Unequal cost multipath) using BGP link-bandwidth: https://tools.ietf.org/html/draft-mohanty-bess-ebgp-dmz The included tests are: Test #1: Test BGP link-bandwidth advertisement based on number of multipaths Test #2: Test cumulative link-bandwidth propagation Test #3: Test weighted ECMP - multipath with next hop weights Test #4: Test weighted ECMP rebalancing upon change (link flap) Test #5: Test weighted ECMP for a second anycast IP Test #6: Test paths with and without link-bandwidth - receiver should resort to regular ECMP Test #7: Test different options for processing link-bandwidth on the receiver Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 17, 2020
This code is called from the zebra main pthread during shutdown but the thread event is scheduled via the zebra dplane pthread. Hence, we should be using the `thread_cancel_async()` API to cancel the thread event on a different pthread. This is only ever hit in the rare case that we still have work left to do on the update queue during shutdown. Found via zebra crash: ``` (gdb) bt \#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 \#1 0x00007f4e4d3f7535 in __GI_abort () at abort.c:79 \#2 0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()", file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92 \#3 0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c", line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101 \#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 \#5 0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274 \#6 0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202 \#7 0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599 \#8 0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024 \#9 0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483 (gdb) down \#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 1185 assert(master->owner == pthread_self()); (gdb) ``` Ticket: CM-27230 Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com> (cherry picked from commit 9344d3f)
qlyoung
pushed a commit
that referenced
this pull request
Jun 17, 2020
We were not connecting the default zebra_ns to the default ns->info at namespace initialization in zebra. Thus, when we tried to use the `ns_walk_func()` it would ignore the default zebra_ns since there is no pointer to it from the ns struct. Fix this by connecting them in `zebra_ns_init()` and, if the default ns is not found, exit with failure since this is not recoverable. This was found during a crash where we fail to cancel the kernel_read thread at termination (via the `ns_walk_func()`) and then we get a netlink notification trying to use the zns struct that has already been freed. ``` (gdb) bt \#0 0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 \#1 0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 \#2 0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254 \#3 <signal handler called> \#4 0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269 \#5 0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043 \#6 0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384 \#7 0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940, count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932 \#8 0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406 \#9 0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599 \FRRouting#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024 \FRRouting#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483 ``` Ticket: CM-27294 Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com> (cherry picked from commit 257b245)
qlyoung
pushed a commit
that referenced
this pull request
Jun 17, 2020
Running with --enable-address-sanitizer I am seeing this: ================================================================= ==19520==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ef850 at pc 0x7fe9b8f7b57b bp 0x7fffbac6f9c0 sp 0x7fffbac6f170 READ of size 6 at 0x6020003ef850 thread T0 #0 0x7fe9b8f7b57a (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x55e33d1071e5 in bgp_process_mac_rescan_table bgpd/bgp_mac.c:159 #2 0x55e33d107c09 in bgp_mac_rescan_evpn_table bgpd/bgp_mac.c:252 #3 0x55e33d107e39 in bgp_mac_rescan_all_evpn_tables bgpd/bgp_mac.c:266 #4 0x55e33d108270 in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:291 #5 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 #6 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 #7 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 #8 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 #9 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 FRRouting#10 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#11 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#12 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#13 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 FRRouting#14 0x55e33d09c189 in _start (/usr/lib/frr/bgpd+0x168189) 0x6020003ef850 is located 0 bytes inside of 16-byte region [0x6020003ef850,0x6020003ef860) freed by thread T0 here: #0 0x7fe9b8fabfb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0) #1 0x7fe9b8ce4ea9 in qfree lib/memory.c:129 #2 0x55e33d10825c in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:289 #3 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 #4 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 #5 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 #6 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 #7 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 #8 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 #9 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#10 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#11 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7fe9b8fac518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fe9b8ce4d93 in qcalloc lib/memory.c:110 #2 0x55e33d106b29 in bgp_mac_hash_alloc bgpd/bgp_mac.c:96 #3 0x7fe9b8cb8350 in hash_get lib/hash.c:149 #4 0x55e33d10845b in bgp_mac_add_mac_entry bgpd/bgp_mac.c:303 #5 0x55e33d226757 in bgp_ifp_create bgpd/bgp_zebra.c:2644 #6 0x7fe9b8cbf1e6 in if_new_via_zapi lib/if.c:176 #7 0x7fe9b8db2d3b in zclient_interface_add lib/zclient.c:1481 #8 0x7fe9b8db87f8 in zclient_read lib/zclient.c:2659 #9 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#10 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#11 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#12 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 Effectively we are passing to bgp_mac_remove_ifp_internal the macaddr that is associated with the bsm data structure. There exists a path where the bsm is freed and then we immediately pass the macaddr into bgp_mac_rescan_all_evpn_tables. So just make a copy of the macaddr data structure before we free the bsm Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 17, 2020
================================================================= ==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138 READ of size 8 at 0x60d0000115c8 thread T0 #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041 #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234 #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205 #3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229 #4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541 #5 0x55cb9ceba0af in sigint zebra/main.c:176 #6 0x55cb9ceba0af in sigint zebra/main.c:130 #7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103 #8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396 #9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092 FRRouting#10 0x55cb9ce931d8 in main zebra/main.c:488 FRRouting#11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09) ================================================================= Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Extend generic Sub-TLVs pack function to pack SRv6 End SID Sub-TLVs (RFC 9352 section #7.2). Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Extend SRv6 End SID Sub-TLV copy function to copy Sub-Sub-TLVs (RFC 9352 section #7.2). Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Extend SRv6 End SID Sub-TLV format function to return information about Sub-Sub-TLVs (RFC 9352 section #7.2). Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Add a function to fill in an SRv6 Locator TLV with information from an SRv6 locator (RFC 9352 section #7.1). Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Add a function to fill in an SRv6 End SID Sub-TLV with information from an SRv6 End SID (RFC 9352 section #7.2). Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Add a function to build an SRv6 Locator TLV (RFC 9352 section #7.1) to advertise a specific SRv6 Locator passed as an argument. Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 20, 2023
Add a function to build an SRv6 End SID TLV (RFC 9352 section #7.2) to advertise a specific SRv6 End SID passed as an argument. Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
qlyoung
pushed a commit
that referenced
this pull request
Sep 27, 2023
Fixes a memory leak in ospfd where the external aggregator was not released after its associated route node is deleted. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in ospf_basic_functionality.test_ospf_asbr_summary_topo1/r0.asan.ospfd.31502 ================================================================= ==31502==ERROR: LeakSanitizer: detected memory leaks Direct leak of 200 byte(s) in 5 object(s) allocated from: #0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fdb300620da in qcalloc lib/memory.c:105 #2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396 #3 0x55e53c2dead3 in ospf_asbr_external_aggregator_set ospfd/ospf_asbr.c:1123 #4 0x55e53c27c921 in ospf_external_route_aggregation ospfd/ospf_vty.c:10264 #5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993 #6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051 #7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218 #8 0x7fdb3010ce2a in vty_command lib/vty.c:591 #9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354 FRRouting#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362 FRRouting#11 0x7fdb30100b99 in event_call lib/event.c:1979 FRRouting#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213 FRRouting#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249 FRRouting#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fdb300620da in qcalloc lib/memory.c:105 #2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396 #3 0x55e53c2dedd3 in ospf_asbr_external_rt_no_advertise ospfd/ospf_asbr.c:1182 #4 0x55e53c27cf10 in ospf_external_route_aggregation_no_adrvertise ospfd/ospf_vty.c:10626 #5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993 #6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051 #7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218 #8 0x7fdb3010ce2a in vty_command lib/vty.c:591 #9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354 FRRouting#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362 FRRouting#11 0x7fdb30100b99 in event_call lib/event.c:1979 FRRouting#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213 FRRouting#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249 FRRouting#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 240 byte(s) leaked in 6 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Sep 27, 2023
After the ISIS daemon is launched, the configuration of an srv6 locator in zebra triggers a crash: > #4 0x00007f1f0ea980f3 in core_handler (signo=11, siginfo=0x7ffdb750de70, context=0x7ffdb750dd40) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262 > #5 <signal handler called> > #6 0x00005651a05783ef in isis_zebra_process_srv6_locator_add (cmd=117, zclient=0x5651a21d9bd0, length=25, vrf_id=0) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_zebra.c:1258 > #7 0x00007f1f0ead5ac9 in zclient_read (thread=0x7ffdb750e750) at /build/make-pkg/output/_packages/cp-routing/src/lib/zclient.c:4246 > #8 0x00007f1f0eab19d4 in thread_call (thread=0x7ffdb750e750) at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825 > #9 0x00007f1f0ea4862e in frr_run (master=0x5651a1f65a40) at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155 > FRRouting#10 0x00005651a051131a in main (argc=5, argv=0x7ffdb750e998, envp=0x7ffdb750e9c8) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:282 > (gdb) f 6 > #6 0x00005651a05783ef in isis_zebra_process_srv6_locator_add (cmd=117, zclient=0x5651a21d9bd0, length=25, vrf_id=0) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_zebra.c:1258 > (gdb) print isis > $1 = (struct isis *) 0x0 > (gdb) print isis->area_list > Cannot access memory at address 0x28 The isis pointer is NULL, because no instances have already been configured on the ISIS instance. Fix this by checking that there is any isis instance available when zebra hooks related to srv6 are received. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 16, 2023
`ng` was not properly freed, leading to a memory leak. The commit calls `nexthop_group_delete` to free memory associated with `ng`. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308 ================================================================= ==24308==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270 #3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681 #4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 #8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 #9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 FRRouting#10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 FRRouting#11 0x7f4f475dc7f2 in event_call lib/event.c:1969 FRRouting#12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 FRRouting#13 0x562ded69e818 in main zebra/main.c:486 FRRouting#14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376 #3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914 #4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444 #5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682 #6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 FRRouting#10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 FRRouting#11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 FRRouting#12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 FRRouting#13 0x7f4f475dc7f2 in event_call lib/event.c:1969 FRRouting#14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 FRRouting#15 0x562ded69e818 in main zebra/main.c:486 FRRouting#16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 16, 2023
- Addressed memory leak by removing `&c->peer_notifier` from the notifier list on termination. Retaining it caused the notifier list to stay active, preventing the deletion of `c->cur.peer` thereby causing a memory leak. - Reordered termination steps to call `vrf_terminate` before `nhrp_vc_terminate`, preventing a heap-use-after-free issue when `nhrp_vc_notify_del` is invoked in `nhrp_peer_check_delete`. - Added an if statement to avoid passing NULL as hash to `hash_release`, which leads to a SIGSEGV. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in nhrp_topo.test_nhrp_topo/r1.asan.nhrpd.20265 ================================================================= ==20265==ERROR: LeakSanitizer: detected memory leaks Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x7f80270c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f8026ac1eb8 in qmalloc lib/memory.c:100 #2 0x560fd648f0a6 in nhrp_peer_create nhrpd/nhrp_peer.c:175 #3 0x7f8026a88d3f in hash_get lib/hash.c:147 #4 0x560fd6490a5d in nhrp_peer_get nhrpd/nhrp_peer.c:228 #5 0x560fd648a51a in nhrp_nhs_resolve_cb nhrpd/nhrp_nhs.c:297 #6 0x7f80266b000f in resolver_cb_literal lib/resolver.c:234 #7 0x7f8026b62e0e in event_call lib/event.c:1969 #8 0x7f8026aa5437 in frr_run lib/libfrr.c:1213 #9 0x560fd6488b4f in main nhrpd/nhrp_main.c:166 FRRouting#10 0x7f8025eb2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s). *********************************************************************************** *********************************************************************************** Address Sanitizer Error detected in nhrp_topo.test_nhrp_topo/r2.asan.nhrpd.20400 ================================================================= ==20400==ERROR: LeakSanitizer: detected memory leaks Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x7fb6e3ca5b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7fb6e369deb8 in qmalloc lib/memory.c:100 #2 0x562652de40a6 in nhrp_peer_create nhrpd/nhrp_peer.c:175 #3 0x7fb6e3664d3f in hash_get lib/hash.c:147 #4 0x562652de5a5d in nhrp_peer_get nhrpd/nhrp_peer.c:228 #5 0x562652de1e8e in nhrp_packet_recvraw nhrpd/nhrp_packet.c:325 #6 0x7fb6e373ee0e in event_call lib/event.c:1969 #7 0x7fb6e3681437 in frr_run lib/libfrr.c:1213 #8 0x562652dddb4f in main nhrpd/nhrp_main.c:166 #9 0x7fb6e2a8ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 16, 2023
The shallow copy of attr wasn't freed when there was no valid label for the momentand the function return therefore creating leaks. The leak below are solved by flushing the shallow copy of attr. Address Sanitizer Error detected in bgp_vpnv6_per_nexthop_label.test_bgp_vpnv6_per_nexthop_label/r1.asan.bgpd.13409 ================================================================= ==13409==ERROR: LeakSanitizer: detected memory leaks Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 FRRouting#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969 #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 FRRouting#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 240 byte(s) in 6 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 120 byte(s) in 3 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #7 0x7f62ccb62b8f in event_call lib/event.c:1969 #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #9 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#10 0x7f62cbae7c86 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 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 FRRouting#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969 #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 FRRouting#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 48 byte(s) in 6 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 24 byte(s) in 3 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #7 0x7f62ccb62b8f in event_call lib/event.c:1969 #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #9 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#10 0x7f62cbae7c86 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 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 FRRouting#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x5623b87e054b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s). *********************************************************************************** Address Sanitizer Error detected in bgp_vpnv4_per_nexthop_label.test_bgp_vpnv4_per_nexthop_label/r1.asan.bgpd.10610 ================================================================= ==10610==ERROR: LeakSanitizer: detected memory leaks Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969 #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f81fc007e20 in vty_command lib/vty.c:591 FRRouting#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f81fc007e20 in vty_command lib/vty.c:591 FRRouting#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 240 byte(s) in 6 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 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 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 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 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581 #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118 #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #7 0x7f81fbffbb8f in event_call lib/event.c:1969 #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #9 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f81fc007e20 in vty_command lib/vty.c:591 FRRouting#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 FRRouting#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 FRRouting#11 0x7f81fc007e20 in vty_command lib/vty.c:591 FRRouting#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 FRRouting#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 FRRouting#14 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#16 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969 #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 48 byte(s) in 6 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 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 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 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 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581 #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118 #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 FRRouting#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 FRRouting#11 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #7 0x7f81fbffbb8f in event_call lib/event.c:1969 #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #9 0x55cdc9af854b in main bgpd/bgp_main.c:510 FRRouting#10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s). *********************************************************************************** Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 16, 2023
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 FRRouting#10 0x7f6e844dfe3b in vty_command lib/vty.c:594 FRRouting#11 0x7f6e844e02e6 in vty_execute lib/vty.c:1357 FRRouting#12 0x7f6e844e8bb7 in vtysh_read lib/vty.c:2365 FRRouting#13 0x7f6e844d3b7a in event_call lib/event.c:1965 FRRouting#14 0x7f6e844172b0 in frr_run lib/libfrr.c:1214 FRRouting#15 0x564dcaa50e81 in main zebra/main.c:488 FRRouting#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) ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com> Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
qlyoung
pushed a commit
that referenced
this pull request
Nov 16, 2023
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 ================================================================= ==32320==ERROR: LeakSanitizer: detected memory leaks 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 FRRouting#10 0x7f4ee7bdde37 in vtysh_read lib/vty.c:2365 FRRouting#11 0x7f4ee7bc8dfa in event_call lib/event.c:1965 FRRouting#12 0x7f4ee7b0c3bf in frr_run lib/libfrr.c:1214 FRRouting#13 0x5582be671252 in main sharpd/sharp_main.c:188 FRRouting#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). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
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 FRRouting#10 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#11 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#12 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721 FRRouting#11 0x7fd0a455a7aa in hash_walk lib/hash.c:270 FRRouting#12 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062 FRRouting#13 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071 FRRouting#14 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769 FRRouting#15 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501 FRRouting#16 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683 FRRouting#17 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870 FRRouting#18 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695 FRRouting#19 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#20 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#21 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#11 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368 FRRouting#12 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#13 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#14 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#11 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685 FRRouting#12 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721 FRRouting#13 0x7fd0a455a7aa in hash_walk lib/hash.c:270 FRRouting#14 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062 FRRouting#15 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071 FRRouting#16 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769 FRRouting#17 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501 FRRouting#18 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683 FRRouting#19 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870 FRRouting#20 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695 FRRouting#21 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#22 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#23 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765 FRRouting#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#12 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685 FRRouting#13 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721 FRRouting#14 0x7fd0a455a7aa in hash_walk lib/hash.c:270 FRRouting#15 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062 FRRouting#16 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071 FRRouting#17 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769 FRRouting#18 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501 FRRouting#19 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683 FRRouting#20 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870 FRRouting#21 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695 FRRouting#22 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#23 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#24 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765 FRRouting#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#12 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368 FRRouting#13 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#14 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#15 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990 FRRouting#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765 FRRouting#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#13 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368 FRRouting#14 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#15 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#16 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990 FRRouting#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765 FRRouting#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818 FRRouting#13 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685 FRRouting#14 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721 FRRouting#15 0x7fd0a455a7aa in hash_walk lib/hash.c:270 FRRouting#16 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062 FRRouting#17 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071 FRRouting#18 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769 FRRouting#19 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501 FRRouting#20 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683 FRRouting#21 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870 FRRouting#22 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695 FRRouting#23 0x7fd0a463322a in event_call lib/event.c:1970 FRRouting#24 0x7fd0a4576566 in frr_run lib/libfrr.c:1214 FRRouting#25 0x562b62dbd8f1 in main bgpd/bgp_main.c:510 FRRouting#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>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
Fix a crash because a use-after-free. > ================================================================= > ==1249835==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000074210 at pc 0x7fa1b42a652c bp 0x7ffc477a2aa0 sp 0x7ffc477a2a98 > READ of size 8 at 0x604000074210 thread T0 > #0 0x7fa1b42a652b in list_delete_all_node git/frr/lib/linklist.c:299:20 > #1 0x7fa1b42a683f in list_delete git/frr/lib/linklist.c:312:2 > #2 0x5ee515 in dplane_ctx_free_internal git/frr/zebra/zebra_dplane.c:858:4 > #3 0x5ee59c in dplane_ctx_free git/frr/zebra/zebra_dplane.c:884:2 > #4 0x5ee544 in dplane_ctx_fini git/frr/zebra/zebra_dplane.c:905:2 > #5 0x7045c0 in rib_process_dplane_results git/frr/zebra/zebra_rib.c:4928:4 > #6 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2 > #7 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3 > #8 0x556808 in main git/frr/zebra/main.c:488:2 > #9 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 > FRRouting#10 0x4453e9 in _start (/usr/lib/frr/zebra+0x4453e9) > > 0x604000074210 is located 0 bytes inside of 40-byte region [0x604000074210,0x604000074238) > freed by thread T0 here: > #0 0x4bf1dd in free (/usr/lib/frr/zebra+0x4bf1dd) > #1 0x7fa1b42df0c0 in qfree git/frr/lib/memory.c:130:2 > #2 0x7fa1b42a68ce in list_free_internal git/frr/lib/linklist.c:24:2 > #3 0x7fa1b42a6870 in list_delete git/frr/lib/linklist.c:313:2 > #4 0x5ee515 in dplane_ctx_free_internal git/frr/zebra/zebra_dplane.c:858:4 > #5 0x5ee59c in dplane_ctx_free git/frr/zebra/zebra_dplane.c:884:2 > #6 0x5ee544 in dplane_ctx_fini git/frr/zebra/zebra_dplane.c:905:2 > #7 0x7045c0 in rib_process_dplane_results git/frr/zebra/zebra_rib.c:4928:4 > #8 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2 > #9 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3 > FRRouting#10 0x556808 in main git/frr/zebra/main.c:488:2 > FRRouting#11 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 > > previously allocated by thread T0 here: > #0 0x4bf5d2 in calloc (/usr/lib/frr/zebra+0x4bf5d2) > #1 0x7fa1b42dee18 in qcalloc git/frr/lib/memory.c:105:27 > #2 0x7fa1b42a3784 in list_new git/frr/lib/linklist.c:18:9 > #3 0x6d165f in pbr_iptable_alloc_intern git/frr/zebra/zebra_pbr.c:1015:29 > #4 0x7fa1b426ad1f in hash_get git/frr/lib/hash.c:147:13 > #5 0x6d15f2 in zebra_pbr_add_iptable git/frr/zebra/zebra_pbr.c:1030:13 > #6 0x5db2a3 in zread_iptable git/frr/zebra/zapi_msg.c:3759:3 > #7 0x5e365d in zserv_handle_commands git/frr/zebra/zapi_msg.c:4039:3 > #8 0x7e09fc in zserv_process_messages git/frr/zebra/zserv.c:520:3 > #9 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2 > FRRouting#10 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3 > FRRouting#11 0x556808 in main git/frr/zebra/main.c:488:2 > FRRouting#12 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 Fixes: 1cc3806 ("zebra: Actually free all memory associated ctx->u.iptable.interface_name_list") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
Fix bgp_best_selection heap-use-after-free > ==2521540==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000032810 at pc 0x000000716f45 bp 0x7ffedc6229d0 sp 0x7ffedc6229c8 > READ of size 8 at 0x60d000032810 thread T0 > #0 0x716f44 in bgp_best_selection /home/lscalber/git/frr/bgpd/bgp_route.c:2834:5 > #1 0x71a05e in bgp_process_main_one /home/lscalber/git/frr/bgpd/bgp_route.c:3344:2 > #2 0x71c265 in bgp_process_wq /home/lscalber/git/frr/bgpd/bgp_route.c:3622:3 > #3 0x7fe630a6669c in work_queue_run /home/lscalber/git/frr/lib/workqueue.c:282:10 > #4 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2 > #5 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3 > #6 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2 > #7 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 > #8 0x449629 in _start (/usr/lib/frr/bgpd+0x449629) > > 0x60d000032810 is located 48 bytes inside of 144-byte region [0x60d0000327e0,0x60d000032870) > freed by thread T0 here: > #0 0x4c341d in free (/usr/lib/frr/bgpd+0x4c341d) > #1 0x7fe6308d7420 in qfree /home/lscalber/git/frr/lib/memory.c:130:2 > #2 0x702632 in bgp_path_info_free_with_caller /home/lscalber/git/frr/bgpd/bgp_route.c:300:2 > #3 0x702023 in bgp_path_info_unlock /home/lscalber/git/frr/bgpd/bgp_route.c:315:3 > #4 0x703bc6 in bgp_path_info_reap /home/lscalber/git/frr/bgpd/bgp_route.c:461:2 > #5 0x716e5d in bgp_best_selection /home/lscalber/git/frr/bgpd/bgp_route.c:2829:12 > #6 0x71a05e in bgp_process_main_one /home/lscalber/git/frr/bgpd/bgp_route.c:3344:2 > #7 0x71c265 in bgp_process_wq /home/lscalber/git/frr/bgpd/bgp_route.c:3622:3 > #8 0x7fe630a6669c in work_queue_run /home/lscalber/git/frr/lib/workqueue.c:282:10 > #9 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2 > FRRouting#10 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3 > FRRouting#11 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2 > FRRouting#12 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 > > previously allocated by thread T0 here: > #0 0x4c3812 in calloc (/usr/lib/frr/bgpd+0x4c3812) > #1 0x7fe6308d7178 in qcalloc /home/lscalber/git/frr/lib/memory.c:105:27 > #2 0x71f5b4 in info_make /home/lscalber/git/frr/bgpd/bgp_route.c:3985:8 > #3 0x725293 in bgp_update /home/lscalber/git/frr/bgpd/bgp_route.c:4881:8 > #4 0x73083d in bgp_nlri_parse_ip /home/lscalber/git/frr/bgpd/bgp_route.c:6230:4 > #5 0x6ba980 in bgp_nlri_parse /home/lscalber/git/frr/bgpd/bgp_packet.c:341:10 > #6 0x6cca2a in bgp_update_receive /home/lscalber/git/frr/bgpd/bgp_packet.c:2412:15 > #7 0x6c6788 in bgp_process_packet /home/lscalber/git/frr/bgpd/bgp_packet.c:3887:11 > #8 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2 > #9 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3 > FRRouting#10 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2 > FRRouting#11 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16 Fixes: ddb5b48 ("bgpd: vpn-vrf route leaking") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
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 FRRouting#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978 FRRouting#11 0x7f5666226034 in event_call lib/event.c:1974 FRRouting#12 0x7f566616942b in frr_run lib/libfrr.c:1214 FRRouting#13 0x55a3b44f319d in main bgpd/bgp_main.c:510 FRRouting#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 FRRouting#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978 FRRouting#11 0x7f5666226034 in event_call lib/event.c:1974 FRRouting#12 0x7f566616942b in frr_run lib/libfrr.c:1214 FRRouting#13 0x55a3b44f319d in main bgpd/bgp_main.c:510 FRRouting#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
Configure hash table cleanup with specific free functions for `zrouter.filter_hash`, `zrouter.qdisc_hash`, and `zrouter.class_hash`. This ensures proper memory cleanup, addressing memory leaks. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in tc_basic.test_tc_basic/r1.asan.zebra.15495 ================================================================= ==15495==ERROR: LeakSanitizer: detected memory leaks Direct leak of 176 byte(s) in 1 object(s) allocated from: #0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fd565afe238 in qcalloc lib/memory.c:105 #2 0x5564521c6c9e in tc_filter_alloc_intern zebra/zebra_tc.c:389 #3 0x7fd565ac49e8 in hash_get lib/hash.c:147 #4 0x5564521c7c74 in zebra_tc_filter_add zebra/zebra_tc.c:409 #5 0x55645210755a in zread_tc_filter zebra/zapi_msg.c:3428 #6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004 #7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520 #8 0x7fd565b9e034 in event_call lib/event.c:1974 #9 0x7fd565ae142b in frr_run lib/libfrr.c:1214 FRRouting#10 0x5564520c14b1 in main zebra/main.c:492 FRRouting#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fd565afe238 in qcalloc lib/memory.c:105 #2 0x5564521c6c6e in tc_class_alloc_intern zebra/zebra_tc.c:239 #3 0x7fd565ac49e8 in hash_get lib/hash.c:147 #4 0x5564521c784f in zebra_tc_class_add zebra/zebra_tc.c:293 #5 0x556452107ce5 in zread_tc_class zebra/zapi_msg.c:3315 #6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004 #7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520 #8 0x7fd565b9e034 in event_call lib/event.c:1974 #9 0x7fd565ae142b in frr_run lib/libfrr.c:1214 FRRouting#10 0x5564520c14b1 in main zebra/main.c:492 FRRouting#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 12 byte(s) in 1 object(s) allocated from: #0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fd565afe238 in qcalloc lib/memory.c:105 #2 0x5564521c6c3e in tc_qdisc_alloc_intern zebra/zebra_tc.c:128 #3 0x7fd565ac49e8 in hash_get lib/hash.c:147 #4 0x5564521c753b in zebra_tc_qdisc_install zebra/zebra_tc.c:184 #5 0x556452108203 in zread_tc_qdisc zebra/zapi_msg.c:3286 #6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004 #7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520 #8 0x7fd565b9e034 in event_call lib/event.c:1974 #9 0x7fd565ae142b in frr_run lib/libfrr.c:1214 FRRouting#10 0x5564520c14b1 in main zebra/main.c:492 FRRouting#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 228 byte(s) leaked in 3 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
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 FRRouting#10 0x7f8d1713f034 in event_call lib/event.c:1974 FRRouting#11 0x7f8d1708242b in frr_run lib/libfrr.c:1214 FRRouting#12 0x55d5db99d19d in main bgpd/bgp_main.c:510 FRRouting#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>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
Fix the following heap-use-after-free > ==82961==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020001e4750 at pc 0x55a8cc7f63ac bp 0x7ffd6948e340 sp 0x7ffd6948e330 > READ of size 8 at 0x6020001e4750 thread T0 > #0 0x55a8cc7f63ab in isis_route_node_cleanup isisd/isis_route.c:335 > #1 0x7ff25ec617c1 in route_node_free lib/table.c:75 > #2 0x7ff25ec619fc in route_table_free lib/table.c:111 > #3 0x7ff25ec61661 in route_table_finish lib/table.c:46 > #4 0x55a8cc800d83 in _isis_spftree_del isisd/isis_spf.c:397 > #5 0x55a8cc800e45 in isis_spftree_clear isisd/isis_spf.c:414 > #6 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020 > #7 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076 > #8 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165 > #9 0x7ff25ec7c4dc in event_call lib/event.c:1970 > FRRouting#10 0x7ff25eb64423 in frr_run lib/libfrr.c:1213 > FRRouting#11 0x55a8cc7799da in main isisd/isis_main.c:318 > FRRouting#12 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#13 0x7ff25e623e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#14 0x55a8cc778e44 in _start (/usr/lib/frr/isisd+0x109e44) > > 0x6020001e4750 is located 0 bytes inside of 16-byte region [0x6020001e4750,0x6020001e4760) > freed by thread T0 here: > #0 0x7ff25f000537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7ff25eb9012e in qfree lib/memory.c:130 > #2 0x55a8cc7f6485 in isis_route_table_info_free isisd/isis_route.c:351 > #3 0x55a8cc800cf4 in _isis_spftree_del isisd/isis_spf.c:395 > #4 0x55a8cc800e45 in isis_spftree_clear isisd/isis_spf.c:414 > #5 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020 > #6 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076 > #7 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165 > #8 0x7ff25ec7c4dc in event_call lib/event.c:1970 > #9 0x7ff25eb64423 in frr_run lib/libfrr.c:1213 > FRRouting#10 0x55a8cc7799da in main isisd/isis_main.c:318 > FRRouting#11 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7ff25f000a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7ff25eb8ffdc in qcalloc lib/memory.c:105 > #2 0x55a8cc7f63eb in isis_route_table_info_alloc isisd/isis_route.c:343 > #3 0x55a8cc80052a in _isis_spftree_init isisd/isis_spf.c:334 > #4 0x55a8cc800e51 in isis_spftree_clear isisd/isis_spf.c:415 > #5 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020 > #6 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076 > #7 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165 > #8 0x7ff25ec7c4dc in event_call lib/event.c:1970 > #9 0x7ff25eb64423 in frr_run lib/libfrr.c:1213 > FRRouting#10 0x55a8cc7799da in main isisd/isis_main.c:318 > FRRouting#11 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: 7153c3c ("isisd: update struct isis_route_info has multiple sr info by algorithm") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
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 > FRRouting#10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#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 > FRRouting#10 0x7f450f327a27 in event_call lib/event.c:1970 > FRRouting#11 0x7f450f21a637 in frr_run lib/libfrr.c:1213 > FRRouting#12 0x56260062fc04 in main bgpd/bgp_main.c:540 > FRRouting#13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: dacf6ec ("bgpd: utility routine to convert flowspec actions into pbr actions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jan 29, 2024
Fix a crash when re-adding a rpki server: > r2# sh run bgpd > [...] > rpki > rpki retry_interval 5 > rpki cache 192.0.2.1 15432 preference 1 > exit > [...] > r2# conf t > r2(config)# rpki > r2(config-rpki)# no rpki cache 192.0.2.1 15432 preference 1 > r2(config-rpki)# do show rpki cache-connection > Cannot find a connected group. > r2(config-rpki)# rpki cache 192.0.2.1 15432 preference 1 > r2(config-rpki)# do show rpki cache-connection > vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error! > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007f3fd2d16e57 in core_handler (signo=11, siginfo=0x7ffffd5931b0, context=0x7ffffd593080) at lib/sigevent.c:246 > #2 <signal handler called> > #3 0x00007f3fd26926b4 in tommy_list_head (list=0x2e322e302e323931) at /home/lscalber/git/rtrlib/./third-party/tommyds/tommylist.h:125 > #4 0x00007f3fd2693812 in rtr_mgr_get_first_group (config=0x55fbf31d7f00) at /home/lscalber/git/rtrlib/rtrlib/rtr_mgr.c:409 > #5 0x00007f3fd2ebef59 in get_connected_group () at bgpd/bgp_rpki.c:718 > #6 0x00007f3fd2ec0b39 in show_rpki_cache_connection_magic (self=0x7f3fd2ec69c0 <show_rpki_cache_connection_cmd>, vty=0x55fbf31f9ef0, argc=3, argv=0x55fbf31f99d0, uj=0x0) > # at bgpd/bgp_rpki.c:1575 > #7 0x00007f3fd2ebd4da in show_rpki_cache_connection (self=0x7f3fd2ec69c0 <show_rpki_cache_connection_cmd>, vty=0x55fbf31f9ef0, argc=3, argv=0x55fbf31f99d0) at ./bgpd/bgp_rpki_clippy.c:648 > #8 0x00007f3fd2c8a142 in cmd_execute_command_real (vline=0x55fbf31f9990, vty=0x55fbf31f9ef0, cmd=0x0, up_level=0) at lib/command.c:978 > #9 0x00007f3fd2c8a25c in cmd_execute_command (vline=0x55fbf31e5260, vty=0x55fbf31f9ef0, cmd=0x0, vtysh=0) at lib/command.c:1028 > FRRouting#10 0x00007f3fd2c8a7f1 in cmd_execute (vty=0x55fbf31f9ef0, cmd=0x55fbf3200680 "do show rpki cache-connection ", matched=0x0, vtysh=0) at lib/command.c:1203 > FRRouting#11 0x00007f3fd2d36548 in vty_command (vty=0x55fbf31f9ef0, buf=0x55fbf3200680 "do show rpki cache-connection ") at lib/vty.c:594 > FRRouting#12 0x00007f3fd2d382e1 in vty_execute (vty=0x55fbf31f9ef0) at lib/vty.c:1357 > FRRouting#13 0x00007f3fd2d3a519 in vtysh_read (thread=0x7ffffd5963c0) at lib/vty.c:2365 > FRRouting#14 0x00007f3fd2d2faf6 in event_call (thread=0x7ffffd5963c0) at lib/event.c:1974 > FRRouting#15 0x00007f3fd2cc238e in frr_run (master=0x55fbf2a0cd60) at lib/libfrr.c:1214 > FRRouting#16 0x000055fbf073de40 in main (argc=9, argv=0x7ffffd596618) at bgpd/bgp_main.c:510 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
Fix this: *********************************************************************************** Address Sanitizer Error detected in zebra_opaque.test_zebra_opaque/r3.asan.zebra.11099 ================================================================= ==11099==ERROR: LeakSanitizer: detected memory leaks Direct leak of 66 byte(s) in 1 object(s) allocated from: #0 0x7f527fc06b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f527f5e852b in qmalloc lib/memory.c:100 #2 0x56418d20832d in zread_route_add zebra/zapi_msg.c:2125 #3 0x56418d215d08 in zserv_handle_commands zebra/zapi_msg.c:4011 #4 0x56418d32ab5b in zserv_process_messages zebra/zserv.c:520 #5 0x7f527f6938d3 in event_call lib/event.c:2003 #6 0x7f527f5cb692 in frr_run lib/libfrr.c:1218 #7 0x56418d1c3336 in main zebra/main.c:508 #8 0x7f527e656c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 66 byte(s) leaked in 1 allocation(s). *********************************************************************************** Code inspection leads to some code paths where the opaque data was not freed up. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
Fix the following crash when logging from rpki_create_socket(): > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007f6e21723798 in core_handler (signo=6, siginfo=0x7f6e1e502ef0, context=0x7f6e1e502dc0) at lib/sigevent.c:248 > #2 <signal handler called> > #3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > #4 0x00007f6e2144e537 in __GI_abort () at abort.c:79 > #5 0x00007f6e2176348e in _zlog_assert_failed (xref=0x7f6e2180c920 <_xref.16>, extra=0x0) at lib/zlog.c:670 > #6 0x00007f6e216b1eda in rcu_read_lock () at lib/frrcu.c:294 > #7 0x00007f6e21762da8 in vzlog_notls (xref=0x0, prio=2, fmt=0x7f6e217afe50 "%s:%d: %s(): assertion (%s) failed", ap=0x7f6e1e504248) at lib/zlog.c:425 > #8 0x00007f6e217632fb in vzlogx (xref=0x0, prio=2, fmt=0x7f6e217afe50 "%s:%d: %s(): assertion (%s) failed", ap=0x7f6e1e504248) at lib/zlog.c:627 > #9 0x00007f6e217621f5 in zlog (prio=2, fmt=0x7f6e217afe50 "%s:%d: %s(): assertion (%s) failed") at lib/zlog.h:73 > FRRouting#10 0x00007f6e21763596 in _zlog_assert_failed (xref=0x7f6e2180c920 <_xref.16>, extra=0x0) at lib/zlog.c:687 > FRRouting#11 0x00007f6e216b1eda in rcu_read_lock () at lib/frrcu.c:294 > FRRouting#12 0x00007f6e21762da8 in vzlog_notls (xref=0x7f6e21a50040 <_xref.68>, prio=4, fmt=0x7f6e21a4999f "getaddrinfo: debug", ap=0x7f6e1e504878) at lib/zlog.c:425 > FRRouting#13 0x00007f6e217632fb in vzlogx (xref=0x7f6e21a50040 <_xref.68>, prio=4, fmt=0x7f6e21a4999f "getaddrinfo: debug", ap=0x7f6e1e504878) at lib/zlog.c:627 > FRRouting#14 0x00007f6e21a3f774 in zlog_ref (xref=0x7f6e21a50040 <_xref.68>, fmt=0x7f6e21a4999f "getaddrinfo: debug") at ./lib/zlog.h:84 > FRRouting#15 0x00007f6e21a451b2 in rpki_create_socket (_cache=0x55729149cc30) at bgpd/bgp_rpki.c:1337 > FRRouting#16 0x00007f6e2120e7b7 in tr_tcp_open (tr_socket=0x5572914d1520) at rtrlib/rtrlib/transport/tcp/tcp_transport.c:111 > FRRouting#17 0x00007f6e2120e212 in tr_open (socket=0x5572914b5e00) at rtrlib/rtrlib/transport/transport.c:16 > FRRouting#18 0x00007f6e2120faa2 in rtr_fsm_start (rtr_socket=0x557290e17180) at rtrlib/rtrlib/rtr/rtr.c:130 > FRRouting#19 0x00007f6e218b7ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 > FRRouting#20 0x00007f6e21527a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 rpki_create_socket() is a hook function called from the rtrlib library. The issue arises because rtrlib initiates its own separate pthread in which it runs the hook, which does not establish an FRR RCU context. Consequently, this leads to failures in the logging mechanism that relies on RCU. Initialize a new FRR pthread context from the rtrlib pthread with a valid RCU context to allow logging from the rpki_create_socket() and dependent functions. Link: FRRouting#15260 Fixes: a951752 ("bgpd: create cache server socket in vrf") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
router bgp 65001 no bgp ebgp-requires-policy neighbor 192.168.1.2 remote-as external neighbor 192.168.1.2 timers 3 10 address-family ipv4 unicast neighbor 192.168.1.2 route-map r2 in exit-address-family ! ip prefix-list p1 seq 5 permit 172.16.255.31/32 ! route-map r2 permit 10 match ip address prefix-list p1 set as-path exclude 65003 route-map r2 permit 20 set as-path exclude all ! we make the following commands bgp as-path access-list FIRST permit ^65 bgp as-path access-list SECOND permit 2 route-map r2 permit 6 set as-path exclude as-path-access-list SECOND and then no bgp as-path access-list SECOND permit 2 clear bgp * we have the following crash in bgp Stack trace of thread 536083: #0 0x00007f87f8aacfe1 raise (libpthread.so.0 + 0x12fe1) #1 0x00007f87f8cf6870 core_handler (libfrr.so.0 + 0xf6870) #2 0x00007f87f8aad140 __restore_rt (libpthread.so.0 + 0x13140) #3 0x00007f87f89a5122 __GI___regexec (libc.so.6 + 0xdf122) #4 0x000055d7f198b4a7 aspath_filter_exclude_acl (bgpd + 0x2054a7) #5 0x000055d7f1902187 route_set_aspath_exclude (bgpd + 0x17c187) #6 0x00007f87f8ce54b0 route_map_apply_ext (libfrr.so.0 + 0xe54b0) #7 0x000055d7f18da925 bgp_input_modifier (bgpd + 0x154925) #8 0x000055d7f18e0647 bgp_update (bgpd + 0x15a647) #9 0x000055d7f18e4772 bgp_nlri_parse_ip (bgpd + 0x15e772) FRRouting#10 0x000055d7f18c38ae bgp_nlri_parse (bgpd + 0x13d8ae) FRRouting#11 0x000055d7f18c6b7a bgp_update_receive (bgpd + 0x140b7a) FRRouting#12 0x000055d7f18c8ff3 bgp_process_packet (bgpd + 0x142ff3) FRRouting#13 0x00007f87f8d0dce0 thread_call (libfrr.so.0 + 0x10dce0) FRRouting#14 0x00007f87f8cacb28 frr_run (libfrr.so.0 + 0xacb28) FRRouting#15 0x000055d7f18435da main (bgpd + 0xbd5da) FRRouting#16 0x00007f87f88e9d0a __libc_start_main (libc.so.6 + 0x23d0a) FRRouting#17 0x000055d7f18415fa _start (bgpd + 0xbb5fa) analysis crash is due to the fact that there were always a pointer from as-path exclude to deleted as-path access list. fix we add a backpointer mechanism to manage the dependency beetween as-path access-list and aspath exclude. Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
The asan memory leak has been detected: > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x7f9066dadd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) > #1 0x7f9066779b5d in qcalloc lib/memory.c:105 > #2 0x556d6ca527c2 in vpn_leak_zebra_vrf_sid_update_per_af bgpd/bgp_mplsvpn.c:389 > #3 0x556d6ca530e1 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:451 > #4 0x556d6ca64b3b in vpn_leak_postchange bgpd/bgp_mplsvpn.h:311 > #5 0x556d6ca64b3b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3751 > #6 0x556d6cb9f116 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3337 > #7 0x7f906685a6b6 in zclient_read lib/zclient.c:4490 > #8 0x7f9066826a32 in event_call lib/event.c:2011 > #9 0x7f906675c444 in frr_run lib/libfrr.c:1217 > FRRouting#10 0x556d6c980d52 in main bgpd/bgp_main.c:545 > FRRouting#11 0x7f9065784c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Fix this by freeing the previous memory chunk. Fixes: b72c9e1 ("bgpd: cli for SRv6 SID alloc to redirect to vrf (step4)") Fixes: 527588a ("bgpd: add support for per-VRF SRv6 SID") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
Fix a couple of memory leaks spotted by Address Sanitizer: ``` ================================================================= ==970960==ERROR: LeakSanitizer: detected memory leaks Direct leak of 592 byte(s) in 2 object(s) allocated from: #0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 #2 0xfeb98ae76138 in srv6_locator_chunk_alloc lib/srv6.c:138 #3 0xb7f3c8508fa0 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:831 #4 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 #5 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 #6 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 #7 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 #8 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 #9 0xfeb98af3d684 in event_call lib/event.c:2011 FRRouting#10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217 FRRouting#11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 FRRouting#12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#14 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c) Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 #2 0xb7f3c8508fd8 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:832 #3 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 #4 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 #5 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 #6 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 #7 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 #8 0xfeb98af3d684 in event_call lib/event.c:2011 #9 0xfeb98ae2788c in frr_run lib/libfrr.c:1217 FRRouting#10 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 FRRouting#11 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#12 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#13 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c) Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 #2 0xb7f3c8506520 in vpn_leak_zebra_vrf_sid_update_per_vrf bgpd/bgp_mplsvpn.c:439 #3 0xb7f3c85068d8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:459 #4 0xb7f3c86f6aec in bgp_ifp_create bgpd/bgp_zebra.c:3345 #5 0xfeb98adfd3f8 in hook_call_if_real lib/if.c:48 #6 0xfeb98adfe750 in if_new_via_zapi lib/if.c:181 #7 0xfeb98af98084 in zclient_interface_add lib/zclient.c:2592 #8 0xfeb98afa6d24 in zclient_read lib/zclient.c:4606 #9 0xfeb98af3d684 in event_call lib/event.c:2011 FRRouting#10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217 FRRouting#11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 FRRouting#12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#14 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c) SUMMARY: AddressSanitizer: 656 byte(s) leaked in 6 allocation(s). ``` Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
> ==2334217==ERROR: AddressSanitizer: heap-use-after-free on address 0x61000001d0a0 at pc 0x563828c8de6f bp 0x7fffbdaee560 sp 0x7fffbdaee558 > READ of size 1 at 0x61000001d0a0 thread T0 > #0 0x563828c8de6e in prefix_sid_cmp isisd/isis_spf.c:187 > #1 0x7f84b8204f71 in hash_get lib/hash.c:142 > #2 0x7f84b82055ec in hash_lookup lib/hash.c:184 > #3 0x563828c8e185 in isis_spf_prefix_sid_lookup isisd/isis_spf.c:209 > #4 0x563828c90642 in isis_spf_add2tent isisd/isis_spf.c:598 > #5 0x563828c91cd0 in process_N isisd/isis_spf.c:824 > #6 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > #7 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > #8 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > #9 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009 > FRRouting#10 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090 > FRRouting#11 0x7f84b835c72d in event_call lib/event.c:2011 > FRRouting#12 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > FRRouting#13 0x563828c21918 in main isisd/isis_main.c:346 > FRRouting#14 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#15 0x563828c20df9 in _start (/usr/lib/frr/isisd+0xf5df9) > > 0x61000001d0a0 is located 96 bytes inside of 184-byte region [0x61000001d040,0x61000001d0f8) > freed by thread T0 here: > #0 0x7f84b88a9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7f84b8263bae in qfree lib/memory.c:130 > #2 0x563828c8e433 in isis_vertex_del isisd/isis_spf.c:249 > #3 0x563828c91c95 in process_N isisd/isis_spf.c:811 > #4 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > #5 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > #6 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > #7 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009 > #8 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090 > #9 0x7f84b835c72d in event_call lib/event.c:2011 > FRRouting#10 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > FRRouting#11 0x563828c21918 in main isisd/isis_main.c:346 > FRRouting#12 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7f84b88aa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f84b8263a6c in qcalloc lib/memory.c:105 > #2 0x563828c8e262 in isis_vertex_new isisd/isis_spf.c:225 > #3 0x563828c904db in isis_spf_add2tent isisd/isis_spf.c:588 > #4 0x563828c91cd0 in process_N isisd/isis_spf.c:824 > #5 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > #6 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > #7 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > #8 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009 > #9 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090 > FRRouting#10 0x7f84b835c72d in event_call lib/event.c:2011 > FRRouting#11 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > FRRouting#12 0x563828c21918 in main isisd/isis_main.c:346 > FRRouting#13 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308 > > SUMMARY: AddressSanitizer: heap-use-after-free isisd/isis_spf.c:187 in prefix_sid_cmp > Shadow bytes around the buggy address: > 0x0c207fffb9c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c207fffb9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa > 0x0c207fffb9e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c207fffb9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa > 0x0c207fffba00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd > =>0x0c207fffba10: fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fa > 0x0c207fffba20: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c207fffba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa > 0x0c207fffba40: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c207fffba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa > 0x0c207fffba60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > Shadow gap: cc > ==2334217==ABORTING Fixes: 2f7cc7b ("isisd: detect Prefix-SID collisions and handle them appropriately") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
qlyoung
pushed a commit
that referenced
this pull request
Jun 25, 2024
Fix a crash when doing "show isis database detail json" in isis_srv6_topo1 topotest. > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fad89524e2c in core_handler (signo=6, siginfo=0x7ffe86a4b8b0, context=0x7ffe86a4b780) at lib/sigevent.c:258 > #2 <signal handler called> > #3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > #4 0x00007fad8904e537 in __GI_abort () at abort.c:79 > #5 0x00007fad8904e40f in __assert_fail_base (fmt=0x7fad891c5688 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fad8a3e70e8 "json_object_get_type(jso) == json_type_object", > file=0x7fad8a3e7064 "./json_object.c", line=590, function=<optimized out>) at assert.c:92 > #6 0x00007fad8905d662 in __GI___assert_fail (assertion=0x7fad8a3e70e8 "json_object_get_type(jso) == json_type_object", file=0x7fad8a3e7064 "./json_object.c", line=590, > function=0x7fad8a3e7440 "json_object_object_add_ex") at assert.c:101 > #7 0x00007fad8a3dfe93 in json_object_object_add_ex () from /lib/x86_64-linux-gnu/libjson-c.so.5 > #8 0x000055708e3f8f7f in format_subsubtlv_srv6_sid_structure (sid_struct=0x602000172b70, buf=0x0, json=0x6040000a21d0, indent=6) at isisd/isis_tlvs.c:2880 > #9 0x000055708e3f9acb in isis_format_subsubtlvs (subsubtlvs=0x602000172b50, buf=0x0, json=0x6040000a21d0, indent=6) at isisd/isis_tlvs.c:3022 > FRRouting#10 0x000055708e3eefb0 in format_item_ext_subtlvs (exts=0x614000047440, buf=0x0, json=0x6040000a2190, indent=2, mtid=2) at isisd/isis_tlvs.c:1313 > FRRouting#11 0x000055708e3fd599 in format_item_extended_reach (mtid=2, i=0x60300015aed0, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:3763 > FRRouting#12 0x000055708e40d46a in format_item (mtid=2, context=ISIS_CONTEXT_LSP, type=ISIS_TLV_MT_REACH, i=0x60300015aed0, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:6789 > FRRouting#13 0x000055708e40d4fc in format_items_ (mtid=2, context=ISIS_CONTEXT_LSP, type=ISIS_TLV_MT_REACH, items=0x60600021d160, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:6804 > FRRouting#14 0x000055708e40edbc in format_mt_items (context=ISIS_CONTEXT_LSP, type=ISIS_TLV_MT_REACH, m=0x6180000845d8, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:7147 > FRRouting#15 0x000055708e4111e9 in format_tlvs (tlvs=0x618000084480, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:7572 > FRRouting#16 0x000055708e4114ce in isis_format_tlvs (tlvs=0x618000084480, json=0x6040000a1bd0) at isisd/isis_tlvs.c:7613 > FRRouting#17 0x000055708e36f167 in lsp_print_detail (lsp=0x612000058b40, vty=0x0, json=0x6040000a1bd0, dynhost=1 '\001', isis=0x60d00001f800) at isisd/isis_lsp.c:785 > FRRouting#18 0x000055708e36f31f in lsp_print_all (vty=0x0, json=0x6040000a0490, head=0x61f000005488, detail=1 '\001', dynhost=1 '\001', isis=0x60d00001f800) at isisd/isis_lsp.c:820 > FRRouting#19 0x000055708e4379fc in show_isis_database_lspdb_json (json=0x6040000a0450, area=0x61f000005480, level=0, lspdb=0x61f000005488, sysid_str=0x0, ui_level=1) at isisd/isisd.c:2683 > FRRouting#20 0x000055708e437ef9 in show_isis_database_json (json=0x6040000a0310, sysid_str=0x0, ui_level=1, isis=0x60d00001f800) at isisd/isisd.c:2754 > FRRouting#21 0x000055708e438357 in show_isis_database_common (vty=0x62e000060400, json=0x6040000a0310, sysid_str=0x0, ui_level=1, isis=0x60d00001f800) at isisd/isisd.c:2788 > FRRouting#22 0x000055708e438591 in show_isis_database (vty=0x62e000060400, json=0x6040000a0310, sysid_str=0x0, ui_level=1, vrf_name=0x7fad89806300 <vrf_default_name> "default", all_vrf=false) > at isisd/isisd.c:2825 > FRRouting#23 0x000055708e43891d in show_database (self=0x55708e5519c0 <show_database_cmd>, vty=0x62e000060400, argc=5, argv=0x6040000a02d0) at isisd/isisd.c:2855 > FRRouting#24 0x00007fad893a9767 in cmd_execute_command_real (vline=0x60300015f220, vty=0x62e000060400, cmd=0x0, up_level=0) at lib/command.c:1002 > FRRouting#25 0x00007fad893a9adc in cmd_execute_command (vline=0x60300015f220, vty=0x62e000060400, cmd=0x0, vtysh=0) at lib/command.c:1061 > FRRouting#26 0x00007fad893aa728 in cmd_execute (vty=0x62e000060400, cmd=0x621000025900 "show isis database detail json ", matched=0x0, vtysh=0) at lib/command.c:1227 Note that prior to 2e670cd, there was no crash but only the last "srv6-sid-structure" was displayed. A "srv6-sid-structure" should be displayed for each "sid". This commit also fix this. Was: > "srv6-lan-endx-sid": [ > { > "sid": "fc00:0:1:1::", > "weight": 0, > "algorithm": "SPF", > "neighbor-id": "0000.0000.0002" > }, > { > "sid": "fc00:0:1:2::", > "weight": 0, > "algorithm": "SPF", > "neighbor-id": "0000.0000.0003" > } > ], > "srv6-sid-structure": { > "loc-block-len": 32, > "loc-node-len": 16, > "func-len": 16, > "arg-len": 0 > }, Now (srv6-sid-structure are identical but they are not always): > "srv6-lan-endx-sid": [ > { > "sid": "fc00:0:1:1::", > "algorithm": "SPF", > "neighbor-id": "0000.0000.0002", > "srv6-sid-structure": { > "loc-block-len": 32, > "loc-node-len": 16, > "func-len": 8, > "arg-len": 0 > }, > }, > { > "sid": "fc00:0:1:2::", > "algorithm": "SPF", > "neighbor-id": "0000.0000.0003", > "srv6-sid-structure": { > "loc-block-len": 32, > "loc-node-len": 16, > "func-len": 16, > "arg-len": 0 > }, > } > ], Fixes: 2e670cd ("isisd: fix display of srv6 subsubtlvs") Fixes: 648a158 ("isisd: Add SRv6 End.X SID to Sub-TLV format func") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.