Bgpafisafi #1

donaldsharp · 2017-01-24T03:36:30Z

First schwag at getting the show bgp commands under control in this crazy crazy world

Allow the specification of a VRF_ALL to be used for CLI. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

The show_adj_route_vpn function is only currently used in conjunction with the KEEP_OLD_VPN_COMMANDS #define. Add this function to that define for the moment. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

The bgp_parse_safi function is never called remove it. Especially as that later commits will properly handle what this function was trying to do. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

The parser was incorrect for the 'set ... vpn nexthop ...' commands. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Create bgp_vty_find_and_parse_afi_safi_vrf that will parse the `show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]]' part of a command and to return the correct spot we are in the command. Cleanup 'dampening parameters' part of this command. Consolidate the creation of the bgp data structure to be a bit cleaner. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Cleanup the bgp bestpath or multipath show commands. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Fix this command to use the correct format for a show command. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

1) Make [<view|vrf> WORD] consistent 2) Fix inconsistent help string 3) Fix the show .. vrf all command Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

…rminated (BUFFER_SIZE_WARNING) Coverity: buffer_size_warning: Calling strncpy with a maximum size argument of 100 bytes on destination array pid_file of size 100 bytes might leave the destination string unterminated. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

… too small (BUFFER_SIZE) Coverity: buffer_size: You might overrun the 108 byte destination string addr.sun_path by writing the maximum 4095 bytes from path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

…ERFLOW) Coverity: string_overflow: You might overrun the 100-character destination string vty_path by writing 4096 characters from vty_sock_path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

…rminated (BUFFER_SIZE_WARNING) Coverity: buffer_size_warning: Calling strncpy with a maximum size argument of 100 bytes on destination array pid_file of size 100 bytes might leave the destination string unterminated. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

… too small (BUFFER_SIZE) Coverity: buffer_size: You might overrun the 108 byte destination string addr.sun_path by writing the maximum 4095 bytes from path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

…ERFLOW) Coverity: string_overflow: You might overrun the 100-character destination string vty_path by writing 4096 characters from vty_sock_path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Before ====== cel-redxp-10# show ip bgp 20.1.3.0/24 BGP routing table entry for 20.1.3.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: top1(10.1.1.2) bottom0(20.1.2.2) 4294967292 20.1.2.2 from bottom0(20.1.2.2) (20.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, bestpath-from-AS -4, best Community: 99:1 AddPath ID: RX 0, TX 92 Last update: Wed Sep 27 16:02:34 2017 cel-redxp-10# After ===== cel-redxp-10# show ip bgp 20.1.3.0/24 BGP routing table entry for 20.1.3.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: bottom0(20.1.2.2) 4294967292 20.1.2.2 from bottom0(20.1.2.2) (20.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, bestpath-from-AS 4294967292, best Community: 99:1 AddPath ID: RX 0, TX 2 Last update: Wed Sep 27 16:07:09 2017 cel-redxp-10#

bgpd: changes for crash seen in BGP on "no rt vpn" bug Id 2667

Avoid displaying default configured local preference as part of bgp route's detail output. Local preference is for iBGP learnt route's. The value could be default (100) or configured value (via routemap or local pref config cmd). show bgp afi safi (brief output) does not display, if the local pref attribute is not set. Similarly, show bgp afi safi detail route output should display if the the attribute is set, and should not display configured value. This way both output would be consistent. The configured local preference can be seen via running-config. Ticket:CM-12769 Reviewed By: Testing Done: eBGP output: show bgp ipv4 45.0.3.0/24 BGP routing table entry for 45.0.3.0/24 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: MSP1(uplink-1) MSP2(uplink-2) Local 0.0.0.0 from 0.0.0.0 (27.0.0.9) Origin incomplete, metric 0, weight 32768, valid,sourced, bestpath-from-AS Local, best AddPath ID: RX 0, TX 7 Last update: Thu Jul 26 02:10:02 2018 iBGP output: show bgp ipv4 unicast 6.0.0.16/32 BGP routing table entry for 6.0.0.16/32 Paths: (1 available, best #1, table default) Not advertised to any peer Local 6.0.0.16 (metric 20) from tor-12(6.0.0.16) (6.0.0.16) Origin incomplete, metric 0, localpref 100, valid, internal, bestpath-from-AS Local, best AddPath ID: RX 0, TX 13 Last update: Thu Jul 26 05:26:18 2018 Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>

updateing to latest FRRrouting

This commit introduces lib/id_alloc, which has facilities for both an ID number allocator, and less efficient ID holding pools. The pools are meant to be a temporary holding area for ID numbers meant to be re-used, and are implemented as a linked-list stack. The allocator itself is much more efficient with memory. Based on sizeof values on my 64 bit desktop, the allocator requires around 155 KiB per million IDs tracked. IDs are ultimately tracked in a bit-map split into many "pages." The allocator tracks a list of pages that have free bits, and which sections of each page have free IDs, so there isn't any scanning required to find a free ID. (The library utility ffs, or "Find First Set," is generally a single CPU instruction.) At the moment, totally empty pages will not be freed, so the memory utilization of this allocator will remain at the high water mark. The initial intended use case is for BGP's TX Addpath IDs to be pulled from an allocator that tracks which IDs are in use, rather than a free running counter. The allocator reserves ID #0 as a sentinel value for an invalid ID numbers, and BGP will want ID #1 reserved as well. To support this, the allocator allows for IDs to be explicitly reserved, though be aware this is only practical to use with low numbered IDs because the allocator must allocate pages in order. Signed-off-by Mitchell Skiba <mskiba@amazon.com>

Update Readme to have correct ordering for frr user

Fixes the following warning when running ripngd with valgrind: ==38== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s) ==38== at 0x5EA1E47: sendmsg (sendmsg.c:28) ==38== by 0x118C48: ripng_send_packet (ripngd.c:226) ==38== by 0x11D1D6: ripng_request (ripngd.c:1924) ==38== by 0x120BD8: ripng_interface_wakeup (ripng_interface.c:666) ==38== by 0x4ECB4B4: thread_call (thread.c:1601) ==38== by 0x4E8D9CE: frr_run (libfrr.c:1011) ==38== by 0x1121C8: main (ripng_main.c:180) ==38== Address 0xffefffc34 is on thread 1's stack ==38== in frame #1, created by ripng_send_packet (ripngd.c:172) Signed-off-by: Renato Westphal <renato@opensourcerouting.org>

Fix the following heap-buffer-overflow: > ==3901635==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020003a5940 at pc 0x56260067bb48 bp 0x7ffe8a4f3840 sp 0x7ffe8a4f3838 > READ of size 4 at 0x6020003a5940 thread T0 > #0 0x56260067bb47 in ecommunity_fill_pbr_action bgpd/bgp_ecommunity.c:1587 > #1 0x5626007a246e in bgp_pbr_build_and_validate_entry bgpd/bgp_pbr.c:939 > #2 0x5626007b25e6 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2933 > #3 0x562600909d18 in bgp_zebra_announce bgpd/bgp_zebra.c:1351 > #4 0x5626007d5efd in bgp_process_main_one bgpd/bgp_route.c:3528 > #5 0x5626007d6b43 in bgp_process_wq bgpd/bgp_route.c:3641 > #6 0x7f450f34c2cc in work_queue_run lib/workqueue.c:266 > #7 0x7f450f327a27 in event_call lib/event.c:1970 > #8 0x7f450f21a637 in frr_run lib/libfrr.c:1213 > #9 0x56260062fc04 in main bgpd/bgp_main.c:540 > #10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x56260062ca29 in _start (/usr/lib/frr/bgpd+0x2e3a29) > > 0x6020003a5940 is located 0 bytes to the right of 16-byte region [0x6020003a5930,0x6020003a5940) > allocated by thread T0 here: > #0 0x7f450f6aa1f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 > #1 0x7f450f244f8a in qrealloc lib/memory.c:112 > #2 0x562600673313 in ecommunity_add_val_internal bgpd/bgp_ecommunity.c:143 > #3 0x5626006735bc in ecommunity_uniq_sort_internal bgpd/bgp_ecommunity.c:193 > #4 0x5626006737e3 in ecommunity_parse_internal bgpd/bgp_ecommunity.c:228 > #5 0x562600673890 in ecommunity_parse bgpd/bgp_ecommunity.c:236 > #6 0x562600640469 in bgp_attr_ext_communities bgpd/bgp_attr.c:2674 > #7 0x562600646eb3 in bgp_attr_parse bgpd/bgp_attr.c:3893 > #8 0x562600791b7e in bgp_update_receive bgpd/bgp_packet.c:2141 > #9 0x56260079ba6b in bgp_process_packet bgpd/bgp_packet.c:3406 > #10 0x7f450f327a27 in event_call lib/event.c:1970 > #11 0x7f450f21a637 in frr_run lib/libfrr.c:1213 > #12 0x56260062fc04 in main bgpd/bgp_main.c:540 > #13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: dacf6ec ("bgpd: utility routine to convert flowspec actions into pbr actions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

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 > #10 0x00007f3fd2c8a7f1 in cmd_execute (vty=0x55fbf31f9ef0, cmd=0x55fbf3200680 "do show rpki cache-connection ", matched=0x0, vtysh=0) at lib/command.c:1203 > #11 0x00007f3fd2d36548 in vty_command (vty=0x55fbf31f9ef0, buf=0x55fbf3200680 "do show rpki cache-connection ") at lib/vty.c:594 > #12 0x00007f3fd2d382e1 in vty_execute (vty=0x55fbf31f9ef0) at lib/vty.c:1357 > #13 0x00007f3fd2d3a519 in vtysh_read (thread=0x7ffffd5963c0) at lib/vty.c:2365 > #14 0x00007f3fd2d2faf6 in event_call (thread=0x7ffffd5963c0) at lib/event.c:1974 > #15 0x00007f3fd2cc238e in frr_run (master=0x55fbf2a0cd60) at lib/libfrr.c:1214 > #16 0x000055fbf073de40 in main (argc=9, argv=0x7ffffd596618) at bgpd/bgp_main.c:510 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

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 > #10 0x7ff25eb64423 in frr_run lib/libfrr.c:1213 > #11 0x55a8cc7799da in main isisd/isis_main.c:318 > #12 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #13 0x7ff25e623e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #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 > #10 0x55a8cc7799da in main isisd/isis_main.c:318 > #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 > #10 0x55a8cc7799da in main isisd/isis_main.c:318 > #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> (cherry picked from commit 9fa9a9d)

Fix the following heap-buffer-overflow: > ==3901635==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020003a5940 at pc 0x56260067bb48 bp 0x7ffe8a4f3840 sp 0x7ffe8a4f3838 > READ of size 4 at 0x6020003a5940 thread T0 > #0 0x56260067bb47 in ecommunity_fill_pbr_action bgpd/bgp_ecommunity.c:1587 > #1 0x5626007a246e in bgp_pbr_build_and_validate_entry bgpd/bgp_pbr.c:939 > #2 0x5626007b25e6 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2933 > #3 0x562600909d18 in bgp_zebra_announce bgpd/bgp_zebra.c:1351 > #4 0x5626007d5efd in bgp_process_main_one bgpd/bgp_route.c:3528 > #5 0x5626007d6b43 in bgp_process_wq bgpd/bgp_route.c:3641 > #6 0x7f450f34c2cc in work_queue_run lib/workqueue.c:266 > #7 0x7f450f327a27 in event_call lib/event.c:1970 > #8 0x7f450f21a637 in frr_run lib/libfrr.c:1213 > #9 0x56260062fc04 in main bgpd/bgp_main.c:540 > #10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x56260062ca29 in _start (/usr/lib/frr/bgpd+0x2e3a29) > > 0x6020003a5940 is located 0 bytes to the right of 16-byte region [0x6020003a5930,0x6020003a5940) > allocated by thread T0 here: > #0 0x7f450f6aa1f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 > #1 0x7f450f244f8a in qrealloc lib/memory.c:112 > #2 0x562600673313 in ecommunity_add_val_internal bgpd/bgp_ecommunity.c:143 > #3 0x5626006735bc in ecommunity_uniq_sort_internal bgpd/bgp_ecommunity.c:193 > #4 0x5626006737e3 in ecommunity_parse_internal bgpd/bgp_ecommunity.c:228 > #5 0x562600673890 in ecommunity_parse bgpd/bgp_ecommunity.c:236 > #6 0x562600640469 in bgp_attr_ext_communities bgpd/bgp_attr.c:2674 > #7 0x562600646eb3 in bgp_attr_parse bgpd/bgp_attr.c:3893 > #8 0x562600791b7e in bgp_update_receive bgpd/bgp_packet.c:2141 > #9 0x56260079ba6b in bgp_process_packet bgpd/bgp_packet.c:3406 > #10 0x7f450f327a27 in event_call lib/event.c:1970 > #11 0x7f450f21a637 in frr_run lib/libfrr.c:1213 > #12 0x56260062fc04 in main bgpd/bgp_main.c:540 > #13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: dacf6ec ("bgpd: utility routine to convert flowspec actions into pbr actions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit 6001c76)

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>

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 > #10 0x00007f6e21763596 in _zlog_assert_failed (xref=0x7f6e2180c920 <_xref.16>, extra=0x0) at lib/zlog.c:687 > #11 0x00007f6e216b1eda in rcu_read_lock () at lib/frrcu.c:294 > #12 0x00007f6e21762da8 in vzlog_notls (xref=0x7f6e21a50040 <_xref.68>, prio=4, fmt=0x7f6e21a4999f "getaddrinfo: debug", ap=0x7f6e1e504878) at lib/zlog.c:425 > #13 0x00007f6e217632fb in vzlogx (xref=0x7f6e21a50040 <_xref.68>, prio=4, fmt=0x7f6e21a4999f "getaddrinfo: debug", ap=0x7f6e1e504878) at lib/zlog.c:627 > #14 0x00007f6e21a3f774 in zlog_ref (xref=0x7f6e21a50040 <_xref.68>, fmt=0x7f6e21a4999f "getaddrinfo: debug") at ./lib/zlog.h:84 > #15 0x00007f6e21a451b2 in rpki_create_socket (_cache=0x55729149cc30) at bgpd/bgp_rpki.c:1337 > #16 0x00007f6e2120e7b7 in tr_tcp_open (tr_socket=0x5572914d1520) at rtrlib/rtrlib/transport/tcp/tcp_transport.c:111 > #17 0x00007f6e2120e212 in tr_open (socket=0x5572914b5e00) at rtrlib/rtrlib/transport/transport.c:16 > #18 0x00007f6e2120faa2 in rtr_fsm_start (rtr_socket=0x557290e17180) at rtrlib/rtrlib/rtr/rtr.c:130 > #19 0x00007f6e218b7ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 > #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>

Fix duplicate definition of frr_affinity_map_cli_info in libfrr.so.0 and libmgmt_be_nb.so.0 > ================================================================= > ==3860488==ERROR: AddressSanitizer: odr-violation (0x7f12c98c4d20): > [1] size=296 'frr_affinity_map_cli_info' lib/affinitymap_cli.c:77:35 > [2] size=296 'frr_affinity_map_cli_info' lib/affinitymap_cli.c:77:35 > These globals were registered at these points: > [1]: > #0 0x7f12c9a36f40 in __asan_register_globals ../../../../src/libsanitizer/asan/asan_globals.cpp:341 > #1 0x7f12c9585b7d in _sub_I_00099_1 (/lib/libfrr.so.0+0x185b7d) > #2 0x7f12ca437fe1 in call_init elf/dl-init.c:72 > > [2]: > #0 0x7f12c9a36f40 in __asan_register_globals ../../../../src/libsanitizer/asan/asan_globals.cpp:341 > #1 0x7f12c93824ed in _sub_I_00099_1 (/lib/libmgmt_be_nb.so.0+0x6f4ed) > #2 0x7f12ca437fe1 in call_init elf/dl-init.c:72 > > ==3860488==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 > SUMMARY: AddressSanitizer: odr-violation: global 'frr_affinity_map_cli_info' at lib/affinitymap_cli.c:77:35 > ==3860488==ABORTING Fixes: dc6ff4c ("lib: convert affinity-map to mgmtd") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

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) #10 0x000055d7f18c38ae bgp_nlri_parse (bgpd + 0x13d8ae) #11 0x000055d7f18c6b7a bgp_update_receive (bgpd + 0x140b7a) #12 0x000055d7f18c8ff3 bgp_process_packet (bgpd + 0x142ff3) #13 0x00007f87f8d0dce0 thread_call (libfrr.so.0 + 0x10dce0) #14 0x00007f87f8cacb28 frr_run (libfrr.so.0 + 0xacb28) #15 0x000055d7f18435da main (bgpd + 0xbd5da) #16 0x00007f87f88e9d0a __libc_start_main (libc.so.6 + 0x23d0a) #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>

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) #10 0x000055d7f18c38ae bgp_nlri_parse (bgpd + 0x13d8ae) #11 0x000055d7f18c6b7a bgp_update_receive (bgpd + 0x140b7a) #12 0x000055d7f18c8ff3 bgp_process_packet (bgpd + 0x142ff3) #13 0x00007f87f8d0dce0 thread_call (libfrr.so.0 + 0x10dce0) #14 0x00007f87f8cacb28 frr_run (libfrr.so.0 + 0xacb28) #15 0x000055d7f18435da main (bgpd + 0xbd5da) #16 0x00007f87f88e9d0a __libc_start_main (libc.so.6 + 0x23d0a) #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> (cherry picked from commit 100ef15)

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 > #10 0x556d6c980d52 in main bgpd/bgp_main.c:545 > #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>

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 > #10 0x556d6c980d52 in main bgpd/bgp_main.c:545 > #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> (cherry picked from commit eea8a8a)

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) #10 0x000055d7f18c38ae bgp_nlri_parse (bgpd + 0x13d8ae) #11 0x000055d7f18c6b7a bgp_update_receive (bgpd + 0x140b7a) #12 0x000055d7f18c8ff3 bgp_process_packet (bgpd + 0x142ff3) #13 0x00007f87f8d0dce0 thread_call (libfrr.so.0 + 0x10dce0) #14 0x00007f87f8cacb28 frr_run (libfrr.so.0 + 0xacb28) #15 0x000055d7f18435da main (bgpd + 0xbd5da) #16 0x00007f87f88e9d0a __libc_start_main (libc.so.6 + 0x23d0a) #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> (cherry picked from commit 100ef15)

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 > #10 0x556d6c980d52 in main bgpd/bgp_main.c:545 > #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> (cherry picked from commit eea8a8a)

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>

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)

> ==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>

> ==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)

- 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 #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> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

- 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 #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> (cherry picked from commit d163f89)

- 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 #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> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

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 > #10 0x000055708e3eefb0 in format_item_ext_subtlvs (exts=0x614000047440, buf=0x0, json=0x6040000a2190, indent=2, mtid=2) at isisd/isis_tlvs.c:1313 > #11 0x000055708e3fd599 in format_item_extended_reach (mtid=2, i=0x60300015aed0, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:3763 > #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 > #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 > #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 > #15 0x000055708e4111e9 in format_tlvs (tlvs=0x618000084480, buf=0x0, json=0x6040000a1bd0, indent=0) at isisd/isis_tlvs.c:7572 > #16 0x000055708e4114ce in isis_format_tlvs (tlvs=0x618000084480, json=0x6040000a1bd0) at isisd/isis_tlvs.c:7613 > #17 0x000055708e36f167 in lsp_print_detail (lsp=0x612000058b40, vty=0x0, json=0x6040000a1bd0, dynhost=1 '\001', isis=0x60d00001f800) at isisd/isis_lsp.c:785 > #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 > #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 > #20 0x000055708e437ef9 in show_isis_database_json (json=0x6040000a0310, sysid_str=0x0, ui_level=1, isis=0x60d00001f800) at isisd/isisd.c:2754 > #21 0x000055708e438357 in show_isis_database_common (vty=0x62e000060400, json=0x6040000a0310, sysid_str=0x0, ui_level=1, isis=0x60d00001f800) at isisd/isisd.c:2788 > #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 > #23 0x000055708e43891d in show_database (self=0x55708e5519c0 <show_database_cmd>, vty=0x62e000060400, argc=5, argv=0x6040000a02d0) at isisd/isisd.c:2855 > #24 0x00007fad893a9767 in cmd_execute_command_real (vline=0x60300015f220, vty=0x62e000060400, cmd=0x0, up_level=0) at lib/command.c:1002 > #25 0x00007fad893a9adc in cmd_execute_command (vline=0x60300015f220, vty=0x62e000060400, cmd=0x0, vtysh=0) at lib/command.c:1061 > #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>

…links When a neighbor connection is disconnected, it may trigger LSP re-generation as a timer task, but this process may be delayed. As a result, the list of neighbors in area->adjacency_list may be inconsistent with the neighbors in lsp->tlvs->oldstyle_reach/extended_reach. For example, the area->adjacency_list may lack certain neighbors even though they are present in the LSP. When computing SPF, the call to isis_spf_build_adj_list() generates the spftree->sadj_list, which reflects the real neighbors in the area->adjacency_list. However, in the case of LAN links, spftree->sadj_list may include additional pseudo neighbors. The pre-loading of tents through the call to isis_spf_preload_tent involves two steps: 1. isis_spf_process_lsp() is called to generate real neighbor vertices based on the root LSP and pseudo LSP. 2. isis_spf_add_local() is called to add corresponding next hops to the vertex->Adj_N list for the real neighbor vertices. In the case of LAN links, the absence of corresponding real neighbors in the spftree->sadj_list prevents the execution of the second step. Consequently, the vertex->Adj_N list for the real neighbor vertices lacks corresponding next hops. This leads to a null pointer access when isis_lfa_compute() is called to calculate LFA. As for P2P links, since there are no pseudo neighbors, only the second step is executed, which does not create real neighbor vertices and therefore does not encounter this issue. The backtrace is as follows: (gdb) bt #0 0x00007fd065277fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fd065398972 in core_handler (signo=11, siginfo=0x7ffc5c0636b0, context=0x7ffc5c063580) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 #4 0x00005564d82f8d78 in isis_spf_run_lfa (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_lfa.c:2344 #5 0x00005564d8315964 in isis_run_spf_with_protection (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_spf.c:1827 #6 0x00005564d8315c15 in isis_run_spf_cb (thread=0x7ffc5c064590) at ../isisd/isis_spf.c:1889 #7 0x00007fd0653b1f04 in thread_call (thread=0x7ffc5c064590) at ../lib/thread.c:1990 #8 0x00007fd06534a97b in frr_run (master=0x5564d88103c0) at ../lib/libfrr.c:1198 #9 0x00005564d82e7d5d in main (argc=5, argv=0x7ffc5c0647b8, envp=0x7ffc5c0647e8) at ../isisd/isis_main.c:273 (gdb) f 3 #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 2134 ../isisd/isis_lfa.c: No such file or directory. (gdb) p vadj_primary $1 = (struct isis_vertex_adj *) 0x0 (gdb) p vertex->Adj_N->head $2 = (struct listnode *) 0x0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->data $8 = (struct isis_vertex *) 0x5564d8b5b240 (gdb) p $8->type $9 = VTYPE_NONPSEUDO_TE_IS (gdb) p $8->N.id $10 = "\000\000\000\000\000\002" (gdb) p $8->Adj_N->count $11 = 0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->next->data $12 = (struct isis_vertex *) 0x5564d8b73dd0 (gdb) p $12->type $13 = VTYPE_NONPSEUDO_TE_IS (gdb) p $12->N.id $14 = "\000\000\000\000\000\003" (gdb) p $12->Adj_N->count $15 = 0 (gdb) p area->adjacency_list->count $16 = 0 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. The scenario where a vertex has no next hop is normal. For example, the "clear isis neighbor" command invokes isis_vertex_adj_del() to delete the next hop of a vertex. Upon reviewing all the instances where the vertex->Adj_N list is used, I found that only isis_lfa_compute() lacks a null check. Therefore, I believe that modifying this part will be sufficient. Additionally, the vertex->parents list for IP vertices is guaranteed not to be empty. Test scenario: Setting up LFA for LAN links and executing the "clear isis neighbor" command easily reproduces the issue. Signed-off-by: zhou-run <zhou.run@h3c.com>

…links When a neighbor connection is disconnected, it may trigger LSP re-generation as a timer task, but this process may be delayed. As a result, the list of neighbors in area->adjacency_list may be inconsistent with the neighbors in lsp->tlvs->oldstyle_reach/extended_reach. For example, the area->adjacency_list may lack certain neighbors even though they are present in the LSP. When computing SPF, the call to isis_spf_build_adj_list() generates the spftree->sadj_list, which reflects the real neighbors in the area->adjacency_list. However, in the case of LAN links, spftree->sadj_list may include additional pseudo neighbors. The pre-loading of tents through the call to isis_spf_preload_tent involves two steps: 1. isis_spf_process_lsp() is called to generate real neighbor vertices based on the root LSP and pseudo LSP. 2. isis_spf_add_local() is called to add corresponding next hops to the vertex->Adj_N list for the real neighbor vertices. In the case of LAN links, the absence of corresponding real neighbors in the spftree->sadj_list prevents the execution of the second step. Consequently, the vertex->Adj_N list for the real neighbor vertices lacks corresponding next hops. This leads to a null pointer access when isis_lfa_compute() is called to calculate LFA. As for P2P links, since there are no pseudo neighbors, only the second step is executed, which does not create real neighbor vertices and therefore does not encounter this issue. The backtrace is as follows: (gdb) bt #0 0x00007fd065277fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fd065398972 in core_handler (signo=11, siginfo=0x7ffc5c0636b0, context=0x7ffc5c063580) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 #4 0x00005564d82f8d78 in isis_spf_run_lfa (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_lfa.c:2344 #5 0x00005564d8315964 in isis_run_spf_with_protection (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_spf.c:1827 #6 0x00005564d8315c15 in isis_run_spf_cb (thread=0x7ffc5c064590) at ../isisd/isis_spf.c:1889 #7 0x00007fd0653b1f04 in thread_call (thread=0x7ffc5c064590) at ../lib/thread.c:1990 #8 0x00007fd06534a97b in frr_run (master=0x5564d88103c0) at ../lib/libfrr.c:1198 #9 0x00005564d82e7d5d in main (argc=5, argv=0x7ffc5c0647b8, envp=0x7ffc5c0647e8) at ../isisd/isis_main.c:273 (gdb) f 3 #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 2134 ../isisd/isis_lfa.c: No such file or directory. (gdb) p vadj_primary $1 = (struct isis_vertex_adj *) 0x0 (gdb) p vertex->Adj_N->head $2 = (struct listnode *) 0x0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->data $8 = (struct isis_vertex *) 0x5564d8b5b240 (gdb) p $8->type $9 = VTYPE_NONPSEUDO_TE_IS (gdb) p $8->N.id $10 = "\000\000\000\000\000\002" (gdb) p $8->Adj_N->count $11 = 0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->next->data $12 = (struct isis_vertex *) 0x5564d8b73dd0 (gdb) p $12->type $13 = VTYPE_NONPSEUDO_TE_IS (gdb) p $12->N.id $14 = "\000\000\000\000\000\003" (gdb) p $12->Adj_N->count $15 = 0 (gdb) p area->adjacency_list->count $16 = 0 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. The scenario where a vertex has no next hop is normal. For example, the "clear isis neighbor" command invokes isis_vertex_adj_del() to delete the next hop of a vertex. Upon reviewing all the instances where the vertex->Adj_N list is used, I found that only isis_lfa_compute() lacks a null check. Therefore, I believe that modifying this part will be sufficient. Additionally, the vertex->parents list for IP vertices is guaranteed not to be empty. Test scenario: Setting up LFA for LAN links and executing the "clear isis neighbor" command easily reproduces the issue. Signed-off-by: zhou-run <zhou.run@h3c.com> (cherry picked from commit a970bb5)

donaldsharp added 10 commits January 23, 2017 22:34

lib: Add VRF_ALL define

ece35fd

Allow the specification of a VRF_ALL to be used for CLI. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Fix function used only within KEEP_OLD_VPN_COMMANDS

9dd6d53

The show_adj_route_vpn function is only currently used in conjunction with the KEEP_OLD_VPN_COMMANDS #define. Add this function to that define for the moment. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Remove unused function bgp_parse_safi

3289141

The bgp_parse_safi function is never called remove it. Especially as that later commits will properly handle what this function was trying to do. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Fix vpn commands cli

9fa4d33

The parser was incorrect for the 'set ... vpn nexthop ...' commands. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Cleanup 'show .... <bestpath|multipath>'

c41247f

Cleanup the bgp bestpath or multipath show commands. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgp: Fix 'show .... regexp REGEX...'

b00b230

Fix this command to use the correct format for a show command. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Cleanup 'view all' command

f2a8972

1) Make [<view|vrf> WORD] consistent 2) Fix inconsistent help string 3) Fix the show .. vrf all command Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Cleanup 'show .... statistics' command

e01ca20

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Clean up 'show bgp neighbor ...' commands

30a6a16

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

donaldsharp closed this Jan 24, 2017

mwinter-osr added a commit that referenced this pull request Feb 7, 2017

zebra: Fix CID 1399335 (#1 of 1): Wrong sizeof argument (SIZEOF_MISMA…

2088c0c

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

mwinter-osr added a commit that referenced this pull request Feb 10, 2017

zebra: Fix CID 1399335 (#1 of 1): Wrong sizeof argument (SIZEOF_MISMA…

4fdeb6b

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

mwinter-osr pushed a commit that referenced this pull request Jul 27, 2018

Merge pull request #1 from vishaldhingra/bug_fix

38f423b

bgpd: changes for crash seen in BGP on "no rt vpn" bug Id 2667

mwinter-osr pushed a commit that referenced this pull request Sep 10, 2018

Merge pull request #1 from FRRouting/master

06db5af

updateing to latest FRRrouting

cfra pushed a commit that referenced this pull request Nov 29, 2018

Merge pull request #1 from donaldsharp/fix_ordering

321d359

Update Readme to have correct ordering for frr user

eqvinox added a commit that referenced this pull request Apr 30, 2024

lladdr management #1

6c3e519

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bgpafisafi #1

Bgpafisafi #1

donaldsharp commented Jan 24, 2017

Bgpafisafi #1

Bgpafisafi #1

Conversation

donaldsharp commented Jan 24, 2017