bgpd, lib: fix bgpd core on startup #12

qlyoung · 2016-12-16T22:39:25Z

Fixes #11

Edit: already in master

Signed-off-by: Quentin Young qlyoung@cumulusnetworks.com

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

import Topolog

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 #10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 #11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 #12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 #13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 #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>

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>

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 #10 0x657037 in frr_run lib/libfrr.c:1052 error 09-Oct-2019 19:28:33 #11 0x42d268 in main bgpd/bgp_main.c:486 error 09-Oct-2019 19:28:33 #12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) error 09-Oct-2019 19:28:33 #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: #5025 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

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 FRRouting#1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230 error 09-Oct-2019 19:28:33 FRRouting#2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520 error 09-Oct-2019 19:28:33 FRRouting#3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071 error 09-Oct-2019 19:28:33 FRRouting#4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736 error 09-Oct-2019 19:28:33 FRRouting#5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237 error 09-Oct-2019 19:28:33 FRRouting#6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315 error 09-Oct-2019 19:28:33 FRRouting#7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598 error 09-Oct-2019 19:28:33 FRRouting#8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274 error 09-Oct-2019 19:28:33 FRRouting#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>

The following crash happens when BGP attempts to install a route with a nexthop group group type. > FRRouting#6 0x00005641fa043607 in dplane_route_update_internal (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old_re=0x5641fb5ab180, > FRRouting#7 0x00005641fa043b79 in dplane_route_update (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old_re=0x5641fb5ab180) at zebra/zebra_dplane.c:4549 > FRRouting#8 0x00005641fa08b289 in rib_install_kernel (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old=0x5641fb5ab180) at zebra/zebra_rib.c:737 > FRRouting#9 0x00005641fa08bf46 in rib_process_update_fib (zvrf=0x5641faf96820, rn=0x5641fb5ab460, old=0x5641fb5ab180, new=0x5641fb0a3c50) > FRRouting#10 0x00005641fa08cd48 in rib_process (rn=0x5641fb5ab460) at zebra/zebra_rib.c:1492 > FRRouting#11 0x00005641fa08f9b2 in process_subq_route (lnode=0x5641fb5b5cd0, qindex=8 '\b') at zebra/zebra_rib.c:2666 > FRRouting#12 0x00005641fa0912b2 in process_subq (subq=0x5641faf5ad80, qindex=META_QUEUE_BGP) at zebra/zebra_rib.c:3269 > FRRouting#13 0x00005641fa09139a in meta_queue_process (dummy=0x5641faf5abe0, data=0x5641faf5ac80) at zebra/zebra_rib.c:3308 > FRRouting#14 0x00007f8300599368 in work_queue_run (thread=0x7ffd420c9410) at lib/workqueue.c:282 No need to update the nexthop and consider the route as installed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

The following zebra_rnh sanitizer issue is seen: ==883312==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030001d6388 at pc 0x7f85a0b4ccba bp 0x7ffd7e8356c0 sp 0x7ffd7e8356b0 READ of size 8 at 0x6030001d6388 thread T0 #0 0x7f85a0b4ccb9 in nexthop_vty_helper lib/nexthop.c:1449 FRRouting#1 0x5566125cb0e4 in show_route_nexthop_helper zebra/zebra_rnh.c:1383 FRRouting#2 0x5566125cb6b5 in print_rnh zebra/zebra_rnh.c:1443 FRRouting#3 0x5566125c9078 in zebra_print_rnh_table zebra/zebra_rnh.c:876 FRRouting#4 0x5566125fd5d8 in show_ip_nht_magic zebra/zebra_vty.c:1234 FRRouting#5 0x5566125ea22e in show_ip_nht zebra/zebra_vty_clippy.c:238 FRRouting#6 0x7f85a0a6ac02 in cmd_execute_command_real lib/command.c:982 FRRouting#7 0x7f85a0a6aedf in cmd_execute_command lib/command.c:1032 FRRouting#8 0x7f85a0a6bc61 in cmd_execute lib/command.c:1207 FRRouting#9 0x7f85a0c35de5 in vty_command lib/vty.c:591 FRRouting#10 0x7f85a0c3acca in vty_execute lib/vty.c:1354 FRRouting#11 0x7f85a0c410b8 in vtysh_read lib/vty.c:2362 FRRouting#12 0x7f85a0c25c1a in event_call lib/event.c:2003 FRRouting#13 0x7f85a0af8292 in frr_run lib/libfrr.c:1218 FRRouting#14 0x5566124792cf in main zebra/main.c:508 FRRouting#15 0x7f85a057fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#16 0x7f85a057fe3f in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#17 0x55661242dcb4 in _start (/usr/lib/frr/zebra+0x1adcb4) Ensure to properly parse the NHG, by creating a show_nexthop_group_helper_nhg() function. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

The following nhg asan issue can be seen: ==919564==The signal is caused by a READ memory access. #0 0x560e0d0bd526 in nexthop_valid_resolve zebra/zebra_nhg.c:2015 FRRouting#1 0x560e0d0c0c4a in nexthop_active zebra/zebra_nhg.c:2584 FRRouting#2 0x560e0d0c58c9 in zebra_nhg_proto_add zebra/zebra_nhg.c:3590 FRRouting#3 0x560e0d0f0308 in process_subq_nhg zebra/zebra_rib.c:2629 FRRouting#4 0x560e0d0f4766 in process_subq zebra/zebra_rib.c:3270 FRRouting#5 0x560e0d0f4949 in meta_queue_process zebra/zebra_rib.c:3323 FRRouting#6 0x7ff66c9695b1 in work_queue_run lib/workqueue.c:282 FRRouting#7 0x7ff66c941c1a in event_call lib/event.c:2003 FRRouting#8 0x7ff66c814292 in frr_run lib/libfrr.c:1218 FRRouting#9 0x560e0cfb82cf in main zebra/main.c:508 FRRouting#10 0x7ff66c29bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#11 0x7ff66c29be3f in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#12 0x560e0cf6ccb4 in _start (/usr/lib/frr/zebra+0x1adcb4) Introduce the nexthop_active_resolve_nhg() function to properly parse the resolved nexthops. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

The following crash happens when ZEBRA attempts to check if the nexthop of the route has labeled nexthops or not. > FRRouting#6 0x000055b590b14078 in zebra_rib_labeled_unicast (re=0x55b592b80640) at zebra/zebra_rib.c:671 > FRRouting#7 0x000055b590b14b1a in rib_process_add_fib (zvrf=0x55b592b6a740, rn=0x55b5929f02f0, new=0x55b592b80640) at zebra/zebra_rib.c:994 > FRRouting#8 0x000055b590b15ce9 in rib_process (rn=0x55b5929f02f0) at zebra/zebra_rib.c:1481 > FRRouting#9 0x000055b590b18927 in process_subq_route (lnode=0x55b592b806f0, qindex=8 '\b') at zebra/zebra_rib.c:2653 > FRRouting#10 0x000055b590b1a227 in process_subq (subq=0x55b5928a8d80, qindex=META_QUEUE_BGP) at zebra/zebra_rib.c:3256 > FRRouting#11 0x000055b590b1a30f in meta_queue_process (dummy=0x55b5928a8be0, data=0x55b5928a8c80) at zebra/zebra_rib.c:3295 > FRRouting#12 0x00007fdfd2790368 in work_queue_run (thread=0x7ffd2e913e10) at lib/workqueue.c:282 > FRRouting#13 0x00007fdfd277e5e6 in event_call (thread=0x7ffd2e913e10) at lib/event.c:1974 > FRRouting#14 0x00007fdfd26fcf43 in frr_run (master=0x55b59261aee0) at lib/libfrr.c:1214 > FRRouting#15 0x000055b590a9912b in main (argc=9, argv=0x7ffd2e9140e8) at zebra/main.c:509 When a nexthop group with TYPE_GROUP is used, the dependent nexthop groups must be used instead. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

The following crash happens when BGP attempts to install a route with a nexthop group group type. > FRRouting#6 0x00005641fa043607 in dplane_route_update_internal (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old_re=0x5641fb5ab180, > FRRouting#7 0x00005641fa043b79 in dplane_route_update (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old_re=0x5641fb5ab180) at zebra/zebra_dplane.c:4549 > FRRouting#8 0x00005641fa08b289 in rib_install_kernel (rn=0x5641fb5ab460, re=0x5641fb0a3c50, old=0x5641fb5ab180) at zebra/zebra_rib.c:737 > FRRouting#9 0x00005641fa08bf46 in rib_process_update_fib (zvrf=0x5641faf96820, rn=0x5641fb5ab460, old=0x5641fb5ab180, new=0x5641fb0a3c50) > FRRouting#10 0x00005641fa08cd48 in rib_process (rn=0x5641fb5ab460) at zebra/zebra_rib.c:1492 > FRRouting#11 0x00005641fa08f9b2 in process_subq_route (lnode=0x5641fb5b5cd0, qindex=8 '\b') at zebra/zebra_rib.c:2666 > FRRouting#12 0x00005641fa0912b2 in process_subq (subq=0x5641faf5ad80, qindex=META_QUEUE_BGP) at zebra/zebra_rib.c:3269 > FRRouting#13 0x00005641fa09139a in meta_queue_process (dummy=0x5641faf5abe0, data=0x5641faf5ac80) at zebra/zebra_rib.c:3308 > FRRouting#14 0x00007f8300599368 in work_queue_run (thread=0x7ffd420c9410) at lib/workqueue.c:282 No need to update the nexthop and consider the route as installed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

The following crash has been seen: > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x00007f48a576db78 in core_handler (signo=11, siginfo=0x7ffeee4f2b30, context=0x7ffeee4f2a00) at lib/sigevent.c:262 > #2 <signal handler called> > #3 0x000055aded0d793a in isis_spf_process_lsp (spftree=0x55adee945120, lsp=0x55adee971800, cost=3, depth=1, root_sysid=0x55adee9451ac "", parent=0x55adee9474c0) at isisd/isis_spf.c:887 > FRRouting#4 0x000055aded0d9bd1 in isis_spf_loop (spftree=0x55adee945120, root_sysid=0x55adee9451ac "") at isisd/isis_spf.c:1679 > FRRouting#5 0x000055aded0d9fd1 in isis_run_spf (spftree=0x55adee945120) at isisd/isis_spf.c:1798 > FRRouting#6 0x000055aded0bad65 in isis_spf_run_neighbors (spftree=0x55adee962220) at isisd/isis_lfa.c:1259 > FRRouting#7 0x000055aded0bd896 in isis_spf_run_lfa (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_lfa.c:2291 > FRRouting#8 0x000055aded0da0f2 in isis_run_spf_with_protection (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_spf.c:1817 > FRRouting#9 0x000055aded0da350 in isis_run_spf_cb (thread=0x7ffeee4f3330) at isisd/isis_spf.c:1870 > FRRouting#10 0x00007f48a5786dcc in thread_call (thread=0x7ffeee4f3330) at lib/thread.c:2002 > FRRouting#11 0x00007f48a57213ee in frr_run (master=0x55adee6cdb40) at lib/libfrr.c:1196 > FRRouting#12 0x000055aded0acda2 in main (argc=2, argv=0x7ffeee4f3548, envp=0x7ffeee4f3560) at isisd/isis_main.c:273 It is caused by an attempt to access lsp->tlvs in isis_spf_process_lsp() label lspfragloop when lsp is NULL. isis_spf_process_lsp() checks that the lsp pointer is not NULL at the function beginning but af8ac8f ("isisd: send/receive LSPs with new parser") has introduced some lsp->tlvs accesses after the lspfragloop label without checking that lsp is not NULL. The crash has been seen in the following situation: - ISIS is configured to import routes from BGP - ISIS classic LFA is enabled on all ISIS interfaces - BGP receives routes from an exabgp peers - exabgp is stopped in the middle while sending new prefixes The same situation without LFA does not trigger the bug. However, it seems that the crash can potentially happen without LFA. Fixes: af8ac8f ("isisd: send/receive LSPs with new parser") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

This commit ensures proper cleanup by deleting the gm_join_list when a PIM interface is deleted. The gm_join_list was previously not being freed, causing a memory leak. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in multicast_mld_join_topo1.test_multicast_mld_local_join/r1.asan.pim6d.28070 ================================================================= ==28070==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x56230373dd6b in qcalloc lib/memory.c:105 FRRouting#2 0x56230372180f in list_new lib/linklist.c:49 FRRouting#3 0x56230361b589 in pim_if_gm_join_add pimd/pim_iface.c:1313 FRRouting#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868 FRRouting#5 0x562303767280 in nb_callback_create lib/northbound.c:1235 FRRouting#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579 FRRouting#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710 FRRouting#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104 FRRouting#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137 FRRouting#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49 FRRouting#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88 FRRouting#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991 FRRouting#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053 FRRouting#14 0x5623036c6392 in cmd_execute lib/command.c:1221 FRRouting#15 0x5623037e75da in vty_command lib/vty.c:591 FRRouting#16 0x5623037e7a74 in vty_execute lib/vty.c:1354 FRRouting#17 0x5623037f0253 in vtysh_read lib/vty.c:2362 FRRouting#18 0x5623037db4e8 in event_call lib/event.c:1995 FRRouting#19 0x562303720f97 in frr_run lib/libfrr.c:1213 FRRouting#20 0x56230368615d in main pimd/pim6_main.c:184 FRRouting#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 192 byte(s) in 4 object(s) allocated from: #0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x56230373dd6b in qcalloc lib/memory.c:105 FRRouting#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288 FRRouting#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326 FRRouting#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868 FRRouting#5 0x562303767280 in nb_callback_create lib/northbound.c:1235 FRRouting#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579 FRRouting#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710 FRRouting#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104 FRRouting#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137 FRRouting#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49 FRRouting#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88 FRRouting#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991 FRRouting#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053 FRRouting#14 0x5623036c6392 in cmd_execute lib/command.c:1221 FRRouting#15 0x5623037e75da in vty_command lib/vty.c:591 FRRouting#16 0x5623037e7a74 in vty_execute lib/vty.c:1354 FRRouting#17 0x5623037f0253 in vtysh_read lib/vty.c:2362 FRRouting#18 0x5623037db4e8 in event_call lib/event.c:1995 FRRouting#19 0x562303720f97 in frr_run lib/libfrr.c:1213 FRRouting#20 0x56230368615d in main pimd/pim6_main.c:184 FRRouting#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 96 byte(s) in 4 object(s) allocated from: #0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x56230373dd6b in qcalloc lib/memory.c:105 FRRouting#2 0x562303721651 in listnode_new lib/linklist.c:71 FRRouting#3 0x56230372182b in listnode_add lib/linklist.c:92 FRRouting#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295 FRRouting#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326 FRRouting#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868 FRRouting#7 0x562303767280 in nb_callback_create lib/northbound.c:1235 FRRouting#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579 FRRouting#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710 FRRouting#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104 FRRouting#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137 FRRouting#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49 FRRouting#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88 FRRouting#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991 FRRouting#15 0x5623036c5f1b in cmd_execute_command lib/command.c:1053 FRRouting#16 0x5623036c6392 in cmd_execute lib/command.c:1221 FRRouting#17 0x5623037e75da in vty_command lib/vty.c:591 FRRouting#18 0x5623037e7a74 in vty_execute lib/vty.c:1354 FRRouting#19 0x5623037f0253 in vtysh_read lib/vty.c:2362 FRRouting#20 0x5623037db4e8 in event_call lib/event.c:1995 FRRouting#21 0x562303720f97 in frr_run lib/libfrr.c:1213 FRRouting#22 0x56230368615d in main pimd/pim6_main.c:184 FRRouting#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x56230373dd6b in qcalloc lib/memory.c:105 FRRouting#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288 FRRouting#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326 FRRouting#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868 FRRouting#5 0x562303767280 in nb_callback_create lib/northbound.c:1235 FRRouting#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579 FRRouting#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710 FRRouting#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104 FRRouting#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137 FRRouting#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49 FRRouting#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88 FRRouting#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991 FRRouting#13 0x5623036c5f6f in cmd_execute_command lib/command.c:1072 FRRouting#14 0x5623036c6392 in cmd_execute lib/command.c:1221 FRRouting#15 0x5623037e75da in vty_command lib/vty.c:591 FRRouting#16 0x5623037e7a74 in vty_execute lib/vty.c:1354 FRRouting#17 0x5623037f0253 in vtysh_read lib/vty.c:2362 FRRouting#18 0x5623037db4e8 in event_call lib/event.c:1995 FRRouting#19 0x562303720f97 in frr_run lib/libfrr.c:1213 FRRouting#20 0x56230368615d in main pimd/pim6_main.c:184 FRRouting#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x56230373dd6b in qcalloc lib/memory.c:105 FRRouting#2 0x562303721651 in listnode_new lib/linklist.c:71 FRRouting#3 0x56230372182b in listnode_add lib/linklist.c:92 FRRouting#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295 FRRouting#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326 FRRouting#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868 FRRouting#7 0x562303767280 in nb_callback_create lib/northbound.c:1235 FRRouting#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579 FRRouting#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710 FRRouting#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104 FRRouting#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137 FRRouting#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49 FRRouting#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88 FRRouting#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991 FRRouting#15 0x5623036c5f6f in cmd_execute_command lib/command.c:1072 FRRouting#16 0x5623036c6392 in cmd_execute lib/command.c:1221 FRRouting#17 0x5623037e75da in vty_command lib/vty.c:591 FRRouting#18 0x5623037e7a74 in vty_execute lib/vty.c:1354 FRRouting#19 0x5623037f0253 in vtysh_read lib/vty.c:2362 FRRouting#20 0x5623037db4e8 in event_call lib/event.c:1995 FRRouting#21 0x562303720f97 in frr_run lib/libfrr.c:1213 FRRouting#22 0x56230368615d in main pimd/pim6_main.c:184 FRRouting#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 400 byte(s) leaked in 11 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com> (cherry picked from commit 24379f0)

Fix the following memory leaks found 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 FRRouting#2 0xfeb98ae76138 in srv6_locator_chunk_alloc lib/srv6.c:138 FRRouting#3 0xb7f3c8508fa0 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:831 FRRouting#4 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#5 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#6 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#7 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#8 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#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 FRRouting#2 0xb7f3c8508fd8 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:832 FRRouting#3 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#4 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#5 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#6 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#7 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#8 0xfeb98af3d684 in event_call lib/event.c:2011 FRRouting#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 FRRouting#2 0xb7f3c8506520 in vpn_leak_zebra_vrf_sid_update_per_vrf bgpd/bgp_mplsvpn.c:439 FRRouting#3 0xb7f3c85068d8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:459 FRRouting#4 0xb7f3c86f6aec in bgp_ifp_create bgpd/bgp_zebra.c:3345 FRRouting#5 0xfeb98adfd3f8 in hook_call_if_real lib/if.c:48 FRRouting#6 0xfeb98adfe750 in if_new_via_zapi lib/if.c:181 FRRouting#7 0xfeb98af98084 in zclient_interface_add lib/zclient.c:2592 FRRouting#8 0xfeb98afa6d24 in zclient_read lib/zclient.c:4606 FRRouting#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>

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 FRRouting#2 0xfeb98ae76138 in srv6_locator_chunk_alloc lib/srv6.c:138 FRRouting#3 0xb7f3c8508fa0 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:831 FRRouting#4 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#5 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#6 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#7 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#8 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#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 FRRouting#2 0xb7f3c8508fd8 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:832 FRRouting#3 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#4 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#5 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#6 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#7 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#8 0xfeb98af3d684 in event_call lib/event.c:2011 FRRouting#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 FRRouting#2 0xb7f3c8506520 in vpn_leak_zebra_vrf_sid_update_per_vrf bgpd/bgp_mplsvpn.c:439 FRRouting#3 0xb7f3c85068d8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:459 FRRouting#4 0xb7f3c86f6aec in bgp_ifp_create bgpd/bgp_zebra.c:3345 FRRouting#5 0xfeb98adfd3f8 in hook_call_if_real lib/if.c:48 FRRouting#6 0xfeb98adfe750 in if_new_via_zapi lib/if.c:181 FRRouting#7 0xfeb98af98084 in zclient_interface_add lib/zclient.c:2592 FRRouting#8 0xfeb98afa6d24 in zclient_read lib/zclient.c:4606 FRRouting#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>

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 #10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217 #11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 #12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 #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 #10 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 #11 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #12 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 #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 #10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217 #11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545 #12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392 #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> (cherry picked from commit 65e0111)

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 FRRouting#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 FRRouting#2 0xfeb98ae76138 in srv6_locator_chunk_alloc lib/srv6.c:138 FRRouting#3 0xb7f3c8508fa0 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:831 FRRouting#4 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#5 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#6 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#7 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#8 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#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 FRRouting#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 FRRouting#2 0xb7f3c8508fd8 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:832 FRRouting#3 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866 FRRouting#4 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289 FRRouting#5 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769 FRRouting#6 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378 FRRouting#7 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608 FRRouting#8 0xfeb98af3d684 in event_call lib/event.c:2011 FRRouting#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 FRRouting#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105 FRRouting#2 0xb7f3c8506520 in vpn_leak_zebra_vrf_sid_update_per_vrf bgpd/bgp_mplsvpn.c:439 FRRouting#3 0xb7f3c85068d8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:459 FRRouting#4 0xb7f3c86f6aec in bgp_ifp_create bgpd/bgp_zebra.c:3345 FRRouting#5 0xfeb98adfd3f8 in hook_call_if_real lib/if.c:48 FRRouting#6 0xfeb98adfe750 in if_new_via_zapi lib/if.c:181 FRRouting#7 0xfeb98af98084 in zclient_interface_add lib/zclient.c:2592 FRRouting#8 0xfeb98afa6d24 in zclient_read lib/zclient.c:4606 FRRouting#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>

> ==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 > FRRouting#4 0x563828c90642 in isis_spf_add2tent isisd/isis_spf.c:598 > FRRouting#5 0x563828c91cd0 in process_N isisd/isis_spf.c:824 > FRRouting#6 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > FRRouting#7 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > FRRouting#8 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > FRRouting#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 > FRRouting#4 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > FRRouting#5 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > FRRouting#6 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > FRRouting#7 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009 > FRRouting#8 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090 > FRRouting#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 > FRRouting#4 0x563828c91cd0 in process_N isisd/isis_spf.c:824 > FRRouting#5 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041 > FRRouting#6 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821 > FRRouting#7 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983 > FRRouting#8 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009 > FRRouting#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>

> ==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 > #10 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090 > #11 0x7f84b835c72d in event_call lib/event.c:2011 > #12 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > #13 0x563828c21918 in main isisd/isis_main.c:346 > #14 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308 > #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 > #10 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > #11 0x563828c21918 in main isisd/isis_main.c:346 > #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 > #10 0x7f84b835c72d in event_call lib/event.c:2011 > #11 0x7f84b8236d93 in frr_run lib/libfrr.c:1217 > #12 0x563828c21918 in main isisd/isis_main.c:346 > #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> (cherry picked from commit e697de5)

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 > FRRouting#4 0x00007fad8904e537 in __GI_abort () at abort.c:79 > FRRouting#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 > FRRouting#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 > FRRouting#7 0x00007fad8a3dfe93 in json_object_object_add_ex () from /lib/x86_64-linux-gnu/libjson-c.so.5 > FRRouting#8 0x000055708e3f8f7f in format_subsubtlv_srv6_sid_structure (sid_struct=0x602000172b70, buf=0x0, json=0x6040000a21d0, indent=6) at isisd/isis_tlvs.c:2880 > FRRouting#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 also a crash when several SRv6 End SIDs were present. 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>

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 > FRRouting#4 0x00007fad8904e537 in __GI_abort () at abort.c:79 > FRRouting#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 > FRRouting#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 > FRRouting#7 0x00007fad8a3dfe93 in json_object_object_add_ex () from /lib/x86_64-linux-gnu/libjson-c.so.5 > FRRouting#8 0x000055708e3f8f7f in format_subsubtlv_srv6_sid_structure (sid_struct=0x602000172b70, buf=0x0, json=0x6040000a21d0, indent=6) at isisd/isis_tlvs.c:2880 > FRRouting#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>

Fix the following crash when pim options are (un)configured on an non-existent interface. > r1(config)# int fgljdsf > r1(config-if)# no ip pim unicast-bsm > vtysh: error reading from pimd: Connection reset by peer (104)Warning: closing connection to pimd because of an I/O error! > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007f70c8f32249 in core_handler (signo=11, siginfo=0x7fffff88e4f0, context=0x7fffff88e3c0) at lib/sigevent.c:258 > #2 <signal handler called> > #3 0x0000556cfdd9b16d in lib_interface_pim_address_family_unicast_bsm_modify (args=0x7fffff88f130) at pimd/pim_nb_config.c:1910 > FRRouting#4 0x00007f70c8efdcb5 in nb_callback_modify (context=0x556d00032b60, nb_node=0x556cffeeb9b0, event=NB_EV_APPLY, dnode=0x556d00031670, resource=0x556d00032b48, errmsg=0x7fffff88f710 "", errmsg_len=8192) > at lib/northbound.c:1538 > FRRouting#5 0x00007f70c8efe949 in nb_callback_configuration (context=0x556d00032b60, event=NB_EV_APPLY, change=0x556d00032b10, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1888 > FRRouting#6 0x00007f70c8efee82 in nb_transaction_process (event=NB_EV_APPLY, transaction=0x556d00032b60, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:2016 > FRRouting#7 0x00007f70c8efd658 in nb_candidate_commit_apply (transaction=0x556d00032b60, save_transaction=true, transaction_id=0x0, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1356 > FRRouting#8 0x00007f70c8efd78e in nb_candidate_commit (context=..., candidate=0x556cffeb0e80, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1389 > FRRouting#9 0x00007f70c8f03e58 in nb_cli_classic_commit (vty=0x556d00025a80) at lib/northbound_cli.c:51 > FRRouting#10 0x00007f70c8f043f8 in nb_cli_apply_changes_internal (vty=0x556d00025a80, > xpath_base=0x7fffff893bb0 "/frr-interface:lib/interface[name='fgljdsf']/frr-pim:pim/address-family[address-family='frr-routing:ipv4']", clear_pending=false) at lib/northbound_cli.c:178 > FRRouting#11 0x00007f70c8f0475d in nb_cli_apply_changes (vty=0x556d00025a80, xpath_base_fmt=0x556cfdde9fe0 "./frr-pim:pim/address-family[address-family='%s']") at lib/northbound_cli.c:234 > FRRouting#12 0x0000556cfdd8298f in pim_process_no_unicast_bsm_cmd (vty=0x556d00025a80) at pimd/pim_cmd_common.c:3493 > FRRouting#13 0x0000556cfddcf782 in no_ip_pim_ucast_bsm (self=0x556cfde40b20 <no_ip_pim_ucast_bsm_cmd>, vty=0x556d00025a80, argc=4, argv=0x556d00031500) at pimd/pim_cmd.c:4950 > FRRouting#14 0x00007f70c8e942f0 in cmd_execute_command_real (vline=0x556d00032070, vty=0x556d00025a80, cmd=0x0, up_level=0) at lib/command.c:1002 > FRRouting#15 0x00007f70c8e94451 in cmd_execute_command (vline=0x556d00032070, vty=0x556d00025a80, cmd=0x0, vtysh=0) at lib/command.c:1061 > FRRouting#16 0x00007f70c8e9499f in cmd_execute (vty=0x556d00025a80, cmd=0x556d00030320 "no ip pim unicast-bsm", matched=0x0, vtysh=0) at lib/command.c:1227 > FRRouting#17 0x00007f70c8f51e44 in vty_command (vty=0x556d00025a80, buf=0x556d00030320 "no ip pim unicast-bsm") at lib/vty.c:616 > FRRouting#18 0x00007f70c8f53bdd in vty_execute (vty=0x556d00025a80) at lib/vty.c:1379 > FRRouting#19 0x00007f70c8f55d59 in vtysh_read (thread=0x7fffff896600) at lib/vty.c:2374 > FRRouting#20 0x00007f70c8f4b209 in event_call (thread=0x7fffff896600) at lib/event.c:2011 > FRRouting#21 0x00007f70c8ed109e in frr_run (master=0x556cffdb4ea0) at lib/libfrr.c:1217 > FRRouting#22 0x0000556cfdddec12 in main (argc=2, argv=0x7fffff896828, envp=0x7fffff896840) at pimd/pim_main.c:165 > (gdb) f 3 > #3 0x0000556cfdd9b16d in lib_interface_pim_address_family_unicast_bsm_modify (args=0x7fffff88f130) at pimd/pim_nb_config.c:1910 > 1910 pim_ifp->ucast_bsm_accept = > (gdb) list > 1905 case NB_EV_ABORT: > 1906 break; > 1907 case NB_EV_APPLY: > 1908 ifp = nb_running_get_entry(args->dnode, NULL, true); > 1909 pim_ifp = ifp->info; > 1910 pim_ifp->ucast_bsm_accept = > 1911 yang_dnode_get_bool(args->dnode, NULL); > 1912 > 1913 break; > 1914 } > (gdb) p pim_ifp > $1 = (struct pim_interface *) 0x0 Fixes: 3bb513c ("lib: adapt to version 2 of libyang") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

… the fragmented LSP 1. When the root IS regenerates an LSP, it calls lsp_build() -> lsp_clear_data() to free the TLV memory of the first fragment and all other fragments. If the number of fragments in the regenerated LSP decreases or if no fragmentation is needed, the extra LSP fragments are not immediately deleted. Instead, lsp_seqno_update() -> lsp_purge() is called to set the remaining time to zero and start aging, while also notifying other IS nodes to age these fragments. lsp_purge() usually does not reset lsp->hdr.seqno to zero because the LSP might recover during the aging process. 2. When other IS nodes receive an LSP, they always call process_lsp() -> isis_unpack_tlvs() to allocate TLV memory for the LSP. This does not differentiate whether the received LSP has a remaining lifetime of zero. Therefore, it is rare for an LSP of a non-root IS to have empty TLVs. Of course, if an LSP with a remaining time of zero and already corrupted is received, lsp_update() -> lsp_purge() will be called to free the TLV memory of the LSP, but this scenario is rare. 3. In LFA calculations, neighbors of the root IS are traversed, and each neighbor is taken as a new root to compute the neighbor SPT. During this process, the old root IS will serve as a neighbor of the new root IS, triggering a call to isis_spf_process_lsp() to parse the LSP of the old root IS and obtain its IP vertices and neighboring IS vertices. However, isis_spf_process_lsp() only checks whether the TLVs in the first fragment of the LSP exist, and does not check the TLVs in the fragmented LSP. If the TLV memory of the fragmented LSP of the old root IS has been freed, it can lead to a null pointer access, causing the current crash. Additionally, for the base SPT, there are only two places where the LSP of the root IS is parsed: 1. When obtaining the UP neighbors of the root IS via spf_adj_list_parse_lsp(). 2. When preloading the IP vertices of the root IS via isis_lsp_iterate_ip_reach(). Both of these checks ensure that frag->tlvs is not null, and they do not subsequently call isis_spf_process_lsp() to parse the root IS's LSP. It is very rare for non-root IS LSPs to have empty TLVs unless they are corrupted LSPs awaiting deletion. If it happens, a crash will occur. The backtrace is as follows: (gdb) bt #0 0x00007f3097281fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f30973a2972 in core_handler (signo=11, siginfo=0x7ffce66c2870, context=0x7ffce66c2740) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0) at ../isisd/isis_spf.c:898 #4 0x000055dfa805743b in isis_spf_loop (spftree=0x55dfa950eee0, root_sysid=0x55dfa950ef6c "") at ../isisd/isis_spf.c:1688 #5 0x000055dfa805784f in isis_run_spf (spftree=0x55dfa950eee0) at ../isisd/isis_spf.c:1808 #6 0x000055dfa8037ff5 in isis_spf_run_neighbors (spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:1259 FRRouting#7 0x000055dfa803ac17 in isis_spf_run_lfa (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:2300 FRRouting#8 0x000055dfa8057964 in isis_run_spf_with_protection (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_spf.c:1827 FRRouting#9 0x000055dfa8057c15 in isis_run_spf_cb (thread=0x7ffce66c38e0) at ../isisd/isis_spf.c:1889 FRRouting#10 0x00007f30973bbf04 in thread_call (thread=0x7ffce66c38e0) at ../lib/thread.c:1990 FRRouting#11 0x00007f309735497b in frr_run (master=0x55dfa91733c0) at ../lib/libfrr.c:1198 FRRouting#12 0x000055dfa8029d5d in main (argc=5, argv=0x7ffce66c3b08, envp=0x7ffce66c3b38) at ../isisd/isis_main.c:273 (gdb) f 3 #3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0) at ../isisd/isis_spf.c:898 898 ../isisd/isis_spf.c: No such file or directory. (gdb) p te_neighs $1 = (struct isis_item_list *) 0x120 (gdb) p lsp->tlvs $2 = (struct isis_tlvs *) 0x0 (gdb) p lsp->hdr $3 = {pdu_len = 27, rem_lifetime = 0, lsp_id = "\000\000\000\000\000\001\000\001", seqno = 4, checksum = 59918, lsp_bits = 1 '\001'} The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well. I have reviewed the process for calculating the SPT based on the LSP, and isis_spf_process_lsp() is the only function that does not check whether the TLVs in the fragments are empty. Therefore, I believe that modifying this function alone should be sufficient. If the TLVs of the current fragment are already empty, we do not need to continue processing subsequent fragments. This is consistent with the behavior where we do not process fragments if the TLVs of the first fragment are empty. Of course, one could argue that lsp_purge() should still retain the TLV memory, freeing it and then reallocating it if needed. However, this is a debatable point because in some scenarios, it is permissible for the LSP to have empty TLVs. For example, after receiving an SNP (Sequence Number PDU) message, an empty LSP (with lsp->hdr.seqno = 0) might be created by calling lsp_new. If the corresponding LSP message is discarded due to domain or area authentication failure, the TLV memory wouldn't be allocated. Test scenario: In an LFA network, importing a sufficient number of static routes to cause LSP fragmentation, and then rolling back the imported static routes so that the LSP is no longer fragmented, can easily result in this issue. Signed-off-by: zhou-run <zhou.run@h3c.com>

bgpd, lib: fix bgpd core on startup

23ac345

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

qlyoung closed this Dec 16, 2016

dslicenc mentioned this pull request Feb 6, 2017

zebra and bgp crash at startup in master #170

Closed

qlyoung deleted the bgpd-core-fix branch May 10, 2017 17:41

anithanarasimhamurthy mentioned this pull request May 17, 2017

nhrpd crash on unconfig of nhrp event socket #570

Closed

This was referenced Sep 5, 2017

large-community regex crash #1103

Closed

ospfv3 is failing in topotests #1135

Closed

louberger mentioned this pull request May 15, 2018

Bgpd crash on shutdown when have VRFs and leaked routes #2184

Closed

louberger mentioned this pull request Aug 27, 2018

Abstract void *aggregate pointer in struct route_node #2785

Merged

donaldsharp mentioned this pull request Sep 21, 2018

EIGRP has some bad reads when being shutdown #3065

Closed

mdash-vmware mentioned this pull request Oct 8, 2018

BGPd crashed on 2 routers while running Topotest "test_bgp_l3vpn_to_bgp_vrf.py" #3144

Closed

donaldsharp mentioned this pull request Oct 30, 2018

new Data plane code crashes in CI #3260

Closed

karamalla0406 mentioned this pull request Nov 14, 2018

BGP daemon crash a L2VNI in unconfigured #3333

Closed

vijaykug mentioned this pull request Nov 16, 2018

BGP daemon cored after configuring default-originate in ipv4 label unicast family #3347

Closed

cfra referenced this pull request in opensourcerouting/frr Nov 29, 2018

Merge pull request #12 from opensourcerouting/tgen-log

6b7872c

import Topolog

jasonlittledragon mentioned this pull request Jan 28, 2019

uninstall_element call cause Segmentation fault #3685

Closed

mjstapp mentioned this pull request Mar 5, 2019

Privilege escalation can deadlock #3910

Closed

SathishVenkatesh7 mentioned this pull request Apr 29, 2019

OSPFd: Crashed on Hash table Access on Multiple Scenario's #4223

Closed

louberger mentioned this pull request May 1, 2019

Zebra diet #4236

Merged

kssoman mentioned this pull request Jun 11, 2019

bgpd: Process core when bgp instance is deleted #4499

Merged

karamalla0406 mentioned this pull request Sep 18, 2019

"show bgp l2vpn evpn neighbors 52.1.1.1 advertised-routes json" command results in BGP daemon crash #5010

Closed

donaldsharp mentioned this pull request Sep 20, 2019

BGP VNC is crashing in our Address Sanitizer tests #5025

Closed

donaldsharp mentioned this pull request Nov 1, 2019

bgpd: Prevent usage after free in bgp_mac.c #5260

Merged

louberger mentioned this pull request Nov 3, 2019

bgpd: Send "Peer De-configured" notification before closing the socket #5273

Closed

joolli mentioned this pull request Feb 28, 2024

FRR crash using macvlan interface in a lxc/lxd/incus container #15370

Closed

2 tasks

pguibert6WIND mentioned this pull request Apr 25, 2024

Memory leak in route-map aspath exclude list => aspath_dup() #15836

Open

2 tasks

louis-6wind mentioned this pull request Jun 28, 2024

pimd: fix crash on non-existent interface #16309

Open

zhou-run mentioned this pull request Jul 11, 2024

isisd: (test own)fix crash when calculating the neighbor SPT zhou-run/frr#6

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bgpd, lib: fix bgpd core on startup #12

bgpd, lib: fix bgpd core on startup #12

qlyoung commented Dec 16, 2016 •

edited

Loading

bgpd, lib: fix bgpd core on startup #12

bgpd, lib: fix bgpd core on startup #12

Conversation

qlyoung commented Dec 16, 2016 • edited Loading

qlyoung commented Dec 16, 2016 •

edited

Loading