Flexalgo mpls frrbot2 #2

louis-6wind · 2022-09-12T16:37:11Z

No description provided.

The spftree has a new property called algorithm which is id used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo. In other cases than Flex-Algo, the algorithm id is always zero. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

The information in prefix-sid has a new property called algorithm id. This is used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo.In all other cases, the algorithm id is basically 0. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

The information in prefix-sid has a new property called algorithm id. This is used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo.In all other cases, the algorithm id is basically 0. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Before this commit, SR_ALGORITHM_COUNT was set to 2, and each was hardcoded with router capability tlv. When Flex-Algo is supported, SR-Algorithm may be variably supported up to 256. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

isis_tlvs_add_extended_ip_reach adds IS-IS Extended IP reachability to the LSP. In this case, if the pcfg argument is not NULL, you can add IGP Prefix-SID as its sub tlv. Before this commit, only one Prefix-SID can be added. After this commit, the argument is not a single pointer but an array of pointers, and multiple Prefix-SIDs can be added. This feature is necessary because Flex-Algo requires multiple Prefix-SIDs for each Algorithm. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Prefix-SID nexthops and backup nexthops are stored respectively in isis_route_info->nexthops and isis_route_info->backup->nexthops. With Flex-Algo, there are multiple Prefix-SIDs for a single prefix in different algorithms. Each of these Prefix-SIDs performs SPF calculation with a separate contract and sets a nexthops, so it is necessary to store a different set nexthops for each Prefix-SID. Add a nexthops and backup nethops list into the Prefix-SID isis_sr_psid_info struct and use these lists instead of the when needed After this commit, the nexthops for each Prefix-SID is not taken from route_info, but the nexthop set inside the Prefix-SID is taken. This works for backup nexthops as well. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Before this commit, there was only one sr psid info included in route_info. In fact, in RFC8667, Algorithm ID, which is a property of Prefix-SID, has 8 bits of information. That is, each Prefix can hold up to 256 Prefix-SIDs. This commit implements it. The previously implemented single Prefix-SID will be continued as Algorithm 0. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Many of the enum definitions defined in isis_tlvs.h are often extended at the end. The c/c++ allows commas at the end of a list. This commit simplifies the patching of later extensions. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

SR Algorithms are independent of specific IGPs such as IS-IS and OSPF. This commit adds lib/sr to aggregate IGP agnostic functions and constants. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Philippe Guibert <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Basically in frrouting source code principle, the log string should not be a complicated abstraction or streamlined for grep. But for log format for the "TLV size does not match ..." can be unified, which makes development easier. > $ grep "TLV size does not match expected size for" isisd/isis_tlvs.c > "TLV size does not match expected size for Administrative Group!\n"); > "TLV size does not match expected size for Local IPv6 address!\n"); > ...(snip)... > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > > $ grep "TLV size does not match expected size for" isisd/isis_tlvs.c | wc -l > 25 Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

IS-IS Extensions for Segment Routing (RFC8667) defines a variable length SR-Algorithm Sub-TLV (of the router capability TLV) that includes a list of supported SR algorithms. Each algorithm number is one octet. Only two algorithms were defined at the time 8667 was written: SPF (0) and Strict SPF (1). draft-ietf-lsr-flex-algo-18 reserves the range of algorithm numbers from 128 to 255 for Flex-Algo definitions. As a result, the SR-Algorithm Sub-TLV may now, in practice, hold more than two algorithm identifiers. The internal "struct ls_node", defined in link_state.h, has storage space for only two algorithm IDs. Extend this array to 256 entries. Adjust ls_node comparison logic, etc., to accommodate the longer array. Note that the Router Capability TLV allows a maximum of 250 octets for sub-TLVs and that this is not sufficient to hold a list of all possible algorithm IDs. These changes do not account for that limitation. Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Add the ability to configure a Segment-Routing prefix SID for a given algorithm. For example: > segment-routing prefix 10.10.10.10/32 algorithm 128 index 100 Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Add a function to copy a bitfield_t structure. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Add a library to deal with Flexible Algorithm that will be common to IS-IS and OSPF. The functions enables to deal with: - Affinity-maps - Extended Admin Group (RFC7308) - Flex-Algo structures that contains the flex-algo configurations Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Define the IS-IS flex-algo structure in yang, the CLI configuration commands and the skeletons of frontend and backend functions that are called by the CLI code. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Add a function to returns a human readable string of the metric types that are defined in yang. Signed-off-by: Louis Scalbert <[email protected]>

Signed-off-by: Louis Scalbert <[email protected]>

Adds basic functionality to Flex-Algo for IS-IS wrapping lib/flex_algo. The configuration interface will be added in the next commit. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

Signed-off-by: Louis Scalbert <[email protected]>

Add the backend functions for the flex-algo configuration. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

CID 1519843 (#2 of 2): Uninitialized scalar variable (UNINIT) 43. uninit_use_in_call: Using uninitialized value pkt_src->sin6_addr when calling gm_rx_process Signed-off-by: Mobashshera Rasool <[email protected]>

A isisd crash happens when the IS-IS system-id is defined after a flex-algo definition and before IS-IS segment-routing. After the isisd startup, do: > router isis 1 > is-type level-1 > flex-algo 128 > advertise-definition > dataplane sr-mpls > affinity include-all blue green > net 49.0000.0000.0000.1000.00 It causes this crash: > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fb9403c2ac4 in core_handler (signo=6, siginfo=0x7ffd6a538130, context=0x7ffd6a538000) at /build/tools-build-framework/output/_packages/cp-routing/src/lib/sigevent.c:262 > #2 <signal handler called> > #3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > FRRouting#4 0x00007fb9400c0859 in __GI_abort () at abort.c:79 > FRRouting#5 0x00007fb940400608 in _zlog_assert_failed ( xref=0x559ed6e3baa0 <_xref.21401>, extra=0x0) at /build/tools-build-framework/output/_packages/cp-routing/src/lib/zlog.c:557 > FRRouting#6 0x0000559ed6d8191e in copy_tlv_router_cap (router_cap=0x559ed7d7b8b0) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_tlvs.c:3681 > FRRouting#7 0x0000559ed6d86133 in pack_tlvs (tlvs=0x559ed7d7b4f0, stream=0x559ed7d7c1e0, fragment_tlvs=0x559ed7d7c7d0, new_fragment=0x559ed6d863ab <new_fragment>, new_fragment_arg=0x559ed7d70c50) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_tlvs.c:5393 > FRRouting#8 0x0000559ed6d8644b in isis_fragment_tlvs (tlvs=0x559ed7d7b4f0, size=1470) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_tlvs.c:5476 > FRRouting#9 0x0000559ed6d4b014 in lsp_build (lsp=0x559ed7d7adb0, area=0x559ed7d40a40) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_lsp.c:1361 > FRRouting#10 0x0000559ed6d4b496 in lsp_generate (area=0x559ed7d40a40, level=1) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_lsp.c:1434 > FRRouting#11 0x0000559ed6d9fee5 in isis_instance_area_address_create ( args=0x7ffd6a54fe70) at /build/tools-build-framework/output/_packages/cp-routing/src/isisd/isis_nb_config.c:229 > FRRouting#12 0x00007fb940393e1f in nb_callback_create (context=0x7ffd6a550480, nb_node=0x559ed7b8ad70, event=NB_EV_APPLY, dnode=0x559ed7d54e20, resource=0x559ed7d7aa28, errmsg=0x7ffd6a550490 "", errmsg_len=8192) at /build/tools-build-framework/output/_packages/cp-routing/src/lib/northbound.c:1035 isis_lsp_set_router_capability_fad() only sets cap_fad[fa->algorithm] when segment-routing is enabled. cap_fad[fa->algorithm] admin-group data pointers are not allocated when segment-routing is off. However, when setting the flex-algo definition into router capabilities, cap_fad[fa->algorithm] is copied. Flex-algo definitions are set even segment-routing is not set (which complies with the flex-algo IETF draft). When copying the router capability later, a crash happens because a admin-group pointer is NULL. Set cap_fad[fa->algorithm] even if segment-routing is off. Fixes: 93b0b7f ("isisd: add isis flex-algo lsp advertisement") Signed-off-by: Louis Scalbert <[email protected]>

When shutdown a LAN-type circuit, and if the current device is not the DIS (assuming it is a level-1 device), the isis_circuit_down() function will not call the isis_dr_resign() function to clear the circuit->u.bc.run_dr_elect[0] bit (this bit is set on interfaces in the isis_run_dr() function). After switching the link to a P2P type, since u.p2p and u.bc form a union, and circuit->u.bc.snpa = "\000\000\000\000\000" and circuit->u.bc.run_dr_elect = "\001", this results in circuit->u.p2p.neighbor = 0x1000000000000. Consequently, the value of adj->sysid accesses a wild pointer, causing the current crash. The backtrace is as follows: (gdb) bt #0 0x00007fbd30e55fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fbd30f76b29 in core_handler (signo=11, siginfo=0x7ffc60b7a270, context=0x7ffc60b7a140) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x00007fbd30dddba4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 FRRouting#4 0x0000562aec46617f in isis_spf_run_lfa (area=0x562aee3a56d0, spftree=0x562aee3a51a0) at ../isisd/isis_lfa.c:2403 FRRouting#5 0x0000562aec483854 in isis_run_spf_with_protection (area=0x562aee3a56d0, spftree=0x562aee3a51a0) at ../isisd/isis_spf.c:1891 FRRouting#6 0x0000562aec483b05 in isis_run_spf_cb (thread=0x7ffc60b7b000) at ../isisd/isis_spf.c:1953 FRRouting#7 0x00007fbd30f900bb in thread_call (thread=0x7ffc60b7b000) at ../lib/thread.c:1990 FRRouting#8 0x00007fbd30f2897b in frr_run (master=0x562aee0833c0) at ../lib/libfrr.c:1198 FRRouting#9 0x0000562aec454d6d in main (argc=5, argv=0x7ffc60b7b228, envp=0x7ffc60b7b258) at ../isisd/isis_main.c:273 (gdb) f 4 FRRouting#4 0x0000562aec46617f in isis_spf_run_lfa (area=0x562aee3a56d0, spftree=0x562aee3a51a0) at ../isisd/isis_lfa.c:2403 2403 ../isisd/isis_lfa.c: No such file or directory. (gdb) p circuit->u.p2p.neighbor $1 = (struct isis_adjacency *) 0x1000000000000 (gdb) p adj->sysid Cannot access memory at address 0x1000000000006 (gdb) p circuit->u.bc $2 = {snpa = "\000\000\000\000\000", run_dr_elect = "\001", t_run_dr = {0x0, 0x0}, t_send_lan_hello = {0x0, 0x0}, adjdb = {0x0, 0x0}, lan_neighs = {0x0, 0x0}, is_dr = "\000", l1_desig_is = "\000\000\000\000\000\000", l2_desig_is = "\000\000\000\000\000\000", t_refresh_pseudo_lsp = {0x0, 0x0}} (gdb) 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. Signed-off-by: baozhen-H3C <[email protected]>

Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <[email protected]>

… the neighbor status remains UP Test Scenario: RouterA and RouterB are in the same routing domain and have configured a P2P link. RouterA is configured with "is-type level-1" while RouterB is configured with "is-type level-1-2". They establish a level-1 UP neighborship. In this scenario, we expect that when RouterB's configuration is switched to "is-type level-2-only", the neighborship status on both RouterA and RouterB would be non-UP. However, RouterB still shows the neighbor as UP. Upon receiving a P2P Hello packet, the function "process_p2p_hello" is invoked. According to the ISO/IEC 10589 protocol specification, section 8.2.5.2 a) and tables 5 and 7, if the "iih->circ_type" of the neighbor's hello packet does not match one's own "circuit->is_type," we may choose to take no action. When establishing a neighborship for the first time, the neighbor's status can remain in the "Initializing" state. However, if the neighborship has already been established and one's own "circuit->is_type" changes, the neighbor's UP status cannot be reset. Therefore, when processing P2P Hello packets, we should be cognizant of changes in our own link adjacency type. Topotest has identified a core issue during testing. (gdb) bt "#0 0xb7efe579 in __kernel_vsyscall () \#1 0xb79f62f7 in ?? () \#2 0xbf981dd0 in ?? () \#3 <signal handler called> \FRRouting#4 0xb79f7722 in ?? () \FRRouting#5 0xb7ed8634 in _DYNAMIC () from /home/z15467/isis_core/usr/lib/i386-linux-gnu/frr/libfrr.so.0.0.0 \FRRouting#6 0x0001003c in ?? () \FRRouting#7 0x00010000 in ?? () \FRRouting#8 0xb7df3322 in _frr_mtx_lock (mutex=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/frr_pthread.h:255 \FRRouting#9 event_timer_remain_msec (thread=0x10000) at ../lib/event.c:734 \FRRouting#10 event_timer_remain_msec (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/event.c:727 \FRRouting#11 0x004fb4aa in _send_hello_sched (circuit=<optimized out>, threadp=0x2189de0, level=1, delay=<optimized out>) at ../isisd/isis_pdu.c:2116 \FRRouting#12 0x004e8dbc in isis_circuit_up (circuit=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_circuit.c:734 \FRRouting#13 0x004ea8f7 in isis_csm_state_change (event=<optimized out>, circuit=<optimized out>, arg=<optimized out>) at ../isisd/isis_csm.c:98 \FRRouting#14 0x004ea23f in isis_circuit_circ_type_set (circuit=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, circ_type=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_circuit.c:1578 \FRRouting#15 0x0053aefa in lib_interface_isis_network_type_modify (args=<optimized out>) at ../isisd/isis_nb_config.c:4190 \FRRouting#16 0xb7dbcc8d in nb_callback_modify (errmsg_len=8192, errmsg=0xbf982afc "", resource=0x2186220, dnode=<optimized out>, event=NB_EV_APPLY, nb_node=0x1fafe70, context=<optimized out>) at ../lib/northbound.c:1550 \FRRouting#17 nb_callback_configuration (context=<optimized out>, event=NB_EV_APPLY, change=<optimized out>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:1900 \FRRouting#18 0xb7dbd646 in nb_transaction_process (errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, event=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:2028 \FRRouting#19 nb_candidate_commit_apply (transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, save_transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, transaction_id=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:1368 \FRRouting#20 0xb7dbdd68 in nb_candidate_commit (context=..., candidate=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, save_transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, comment=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, transaction_id=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:1401 \FRRouting#21 0xb7dc0cff in nb_cli_classic_commit (vty=vty@entry=0x21d6940) at ../lib/northbound_cli.c:57 \FRRouting#22 0xb7dc0f46 in nb_cli_apply_changes_internal (vty=vty@entry=0x21d6940, xpath_base=xpath_base@entry=0xbf986b7c "/frr-interface:lib/interface[name='r5-eth0']", clear_pending=clear_pending@entry=false) at ../lib/northbound_cli.c:184 \FRRouting#23 0xb7dc130b in nb_cli_apply_changes (vty=<optimized out>, xpath_base_fmt=<optimized out>) at ../lib/northbound_cli.c:240 \FRRouting#24 0x00542c1d in isis_network_magic (self=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, argc=<optimized out>, argv=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, no=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_cli.c:3101 \FRRouting#25 isis_network (self=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, argc=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, argv=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ./isisd/isis_cli_clippy.c:5499 \FRRouting#26 0xb7d6d8f1 in cmd_execute_command_real (vline=vline@entry=0x219afa0, vty=vty@entry=0x21d6940, cmd=cmd@entry=0x0, up_level=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1003 \FRRouting#27 0xb7d6d9e0 in cmd_execute_command (vline=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, cmd=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vtysh=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1061 \FRRouting#28 0xb7d6dc60 in cmd_execute (vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, cmd=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, matched=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vtysh=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1228 \FRRouting#29 0xb7dfb58a in vty_command (vty=vty@entry=0x21d6940, buf=0x21e0ff0 ' ' <repeats 12 times>, "isis network point-to-point") at ../lib/vty.c:625 \FRRouting#30 0xb7dfc560 in vty_execute (vty=vty@entry=0x21d6940) at ../lib/vty.c:1388 \FRRouting#31 0xb7dfdc8d in vtysh_read (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/vty.c:2400 \FRRouting#32 0xb7df4d47 in event_call (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/event.c:2019 \FRRouting#33 0xb7d9a831 in frr_run (master=<optimized out>) at ../lib/libfrr.c:1232 \FRRouting#34 0x004e4758 in main (argc=7, argv=0xbf989a24, envp=0xbf989a44) at ../isisd/isis_main.c:354 (gdb) f 9 \FRRouting#9 event_timer_remain_msec (thread=0x10000) at ../lib/event.c:734 734 ../lib/event.c: No such file or directory. (gdb) p pthread No symbol "pthread" in current context. (gdb) p thread $1 = (struct event *) 0x10000 When LAN links and P2P links share the` circuit->u` of a neighbor, if one link is no longer in use and the union is not cleared, the other link is unable to pass the non-empty check, resulting in accessing an invalid pointer. Unfortunately, for non-DIS devices in LAN links, `circuit->u.bc.run_dr_elect[x]` is essentially always 1, but in `isis_circuit_down()`,` circuit->u.bc.run_dr_elect[x] `will not be cleared because `circuit->u.bc.is_dr[x]` is always 0. Consequently, when switching to a P2P link, `isis_circuit_circ_type_set()` does not reset the link in a non-C_STATE_UP state, leading to subsequent accesses of `circuit->u.p2p.t_send_p2p_hello` resulting in a non-empty yet invalid address. I believe that in `isis_circuit_down()`, the LAN link should unconditionally clear `circuit->u.bc.run_dr_elect[x]`. Signed-off-by: zhou-run <[email protected]>

The following ASAN error can be seen. > ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20 > #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198 > #1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common > /sanitizer_stacktrace.h:122 > #2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074 > #3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78 > FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130 > FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982 > FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625 > FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019 > FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555 > FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4) > > 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71) > freed by thread T0 here: > #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981 > #2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > #3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625 > FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019 > FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555 > FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101 > #2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194 > #3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236 > FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479 > FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88 > FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936 > FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299 > FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286 > FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275 > FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561 > FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624 > FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019 > FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555 > FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Philippe Guibert <[email protected]>

The following memory leak can be observed when turning off and on the BGP vrf interface. > ==706056==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204 > FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234 > FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57 > FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203 > FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671 > FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624 > FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996 > FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557 > FRRouting#14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627 > FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590 > FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197 > FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996 > FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fix this by freeing the previous open_tx and open_rx contexts before setting up the new one. Also at deletion of peer, free the open_rx context. Signed-off-by: Philippe Guibert <[email protected]>

The following memory leak is observed when running bgp_bmp test. > ==614841==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > #2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211 > #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > #2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207 > #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 64 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f0e9ec77235 in qcalloc lib/memory.c:106 > #2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441 > #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 6 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > #2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814 > #3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493 > FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 5 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > #2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443 > #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s). Fix this by freeing the missing memory block that helps building the open message to send to remote bmp collector. Signed-off-by: Philippe Guibert <[email protected]>

> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0) > ==837617==The signal is caused by a READ memory access. > ==837617==Hint: address points to the zero page. > #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149 > #1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149 > #2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520 > #3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566 > FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234 > FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57 > FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203 > FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671 > FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624 > FRRouting#10 0x7f738998078d in event_call lib/event.c:1996 > FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232 > FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557 > FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234) Signed-off-by: Philippe Guibert <[email protected]>

Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f93ace77233 in qcalloc lib/memory.c:106 > #2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > #3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>

When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>

When staticd receives a `ZAPI_SRV6_SID_RELEASED` notification from SRv6 SID Manager, it tries to unset the validity flag of `sid`. But since the `sid` variable is NULL, we get a NULL pointer dereference. ``` ================================================================= ==13815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000060 (pc 0xc14b813d9eac bp 0xffffcb135a40 sp 0xffffcb135a40 T0) ==13815==The signal is caused by a READ memory access. ==13815==Hint: address points to the zero page. #0 0xc14b813d9eac in static_zebra_srv6_sid_notify staticd/static_zebra.c:1172 #1 0xe44e7aa2c194 in zclient_read lib/zclient.c:4746 #2 0xe44e7a9b69d8 in event_call lib/event.c:1984 #3 0xe44e7a85ac28 in frr_run lib/libfrr.c:1246 FRRouting#4 0xc14b813ccf98 in main staticd/static_main.c:193 FRRouting#5 0xe44e7a4773f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#6 0xe44e7a4774c8 in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#7 0xc14b813cc92c in _start (/usr/lib/frr/staticd+0x1c92c) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV staticd/static_zebra.c:1172 in static_zebra_srv6_sid_notify ==13815==ABORTING ``` This commit fixes the problem by doing a SID lookup first. If the SID can't be found, we log an error and return. If the SID is found, we go ahead and unset the validity flag. Signed-off-by: Carmine Scarpitta <[email protected]>

Upon reconfiguration of the default instance, free the previous pointer. > ================================================================= > ==1209420==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fbde0eaa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fbde0874634 in qcalloc lib/memory.c:106 > #2 0x55dcca019263 in bgp_rtc_plist_entry_asn_new bgpd/bgp_rtc.c:474 > #3 0x55dcca0199f6 in bgp_rtc_plist_entry_add bgpd/bgp_rtc.c:556 > FRRouting#4 0x55dcca01b078 in bgp_rtc_plist_entry_set bgpd/bgp_rtc.c:700 > FRRouting#5 0x55dcca016421 in bgp_nlri_parse_rtc bgpd/bgp_rtc.c:56 > FRRouting#6 0x55dcc9f39f61 in bgp_nlri_parse bgpd/bgp_packet.c:352 > FRRouting#7 0x55dcc9f47628 in bgp_update_receive bgpd/bgp_packet.c:2485 > FRRouting#8 0x55dcc9f54867 in bgp_process_packet bgpd/bgp_packet.c:4114 > FRRouting#9 0x7fbde097aebc in event_call lib/event.c:1984 > FRRouting#10 0x7fbde084710f in frr_run lib/libfrr.c:1246 > FRRouting#11 0x55dcc9dd818b in main bgpd/bgp_main.c:557 > FRRouting#12 0x7fbde044fd79 in __libc_start_main ../csu/libc-start.c:308 Fixes: 4d0e7a4 ("bgpd: VRF-Lite fix default bgp delete") Signed-off-by: Louis Scalbert <[email protected]>

The following ASAN issue has been observed: > ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000acba4 at pc 0x55910c5694d0 bp 0x7ffe3a8ac850 sp 0x7ffe3a8ac840 > READ of size 4 at 0x6160000acba4 thread T0 > #0 0x55910c5694cf in ctx_info_from_zns zebra/zebra_dplane.c:3315 > #1 0x55910c569696 in dplane_ctx_ns_init zebra/zebra_dplane.c:3331 > #2 0x55910c56bf61 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3680 > #3 0x55910c5711ca in dplane_nexthop_update_internal zebra/zebra_dplane.c:4490 > FRRouting#4 0x55910c571c5c in dplane_nexthop_delete zebra/zebra_dplane.c:4717 > FRRouting#5 0x55910c61e90e in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3413 > FRRouting#6 0x55910c615d8a in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1919 > FRRouting#7 0x55910c6404db in route_entry_update_nhe zebra/zebra_rib.c:454 > FRRouting#8 0x55910c64c904 in rib_re_nhg_free zebra/zebra_rib.c:2822 > FRRouting#9 0x55910c655be2 in rib_unlink zebra/zebra_rib.c:4212 > FRRouting#10 0x55910c6430f9 in zebra_rtable_node_cleanup zebra/zebra_rib.c:968 > FRRouting#11 0x7f26f275b8a9 in route_node_free lib/table.c:75 > FRRouting#12 0x7f26f275bae4 in route_table_free lib/table.c:111 > FRRouting#13 0x7f26f275b749 in route_table_finish lib/table.c:46 > FRRouting#14 0x55910c65db17 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x55910c65dfb5 in zebra_router_terminate zebra/zebra_router.c:244 > FRRouting#16 0x55910c4f40db in zebra_finalize zebra/main.c:249 > FRRouting#17 0x7f26f2777108 in event_call lib/event.c:2011 > FRRouting#18 0x7f26f264180e in frr_run lib/libfrr.c:1212 > FRRouting#19 0x55910c4f49cb in main zebra/main.c:531 > FRRouting#20 0x7f26f2029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7f26f2029e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x55910c4b0114 in _start (/usr/lib/frr/zebra+0x1ae114) It happens with FRR using the kernel. During shutdown, the namespace identifier is attempted to be obtained by zebra, in an attempt to prepare zebra dataplane nexthop messages. Fix this by accessing the ns structure. Signed-off-by: Philippe Guibert <[email protected]> (cherry picked from commit 7ae70eb)

When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>

Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <[email protected]>

Issue: Not freeing the neighbor n within the same function can lead to memory leak. zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free Fix: not accessing n after its freed. Directly free the neighbor entry (n) when its interface index matches ifp->ifindex. This fixes: ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0 READ of size 8 at 0x6070001052e8 thread T0 #0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455 #1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34 #2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162 #3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571 FRRouting#4 0x55f95a0f819d in if_down zebra/interface.c:1017 FRRouting#5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102 FRRouting#6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241 FRRouting#7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015 FRRouting#8 0x7f6bf7da3ad9 in event_call lib/event.c:1984 FRRouting#9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246 FRRouting#10 0x55f95a11ca7f in main zebra/main.c:543 FRRouting#11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392 FRRouting#13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4) Ticket: FRRouting#18047 Signed-off-by: Rajesh Varatharaj <[email protected]>

> ==713776==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 120 byte(s) in 1 object(s) allocated from: > #0 0x7fdfcbeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fdfcb86f8dd in qcalloc lib/memory.c:105 > #2 0x55ce707739b6 in isis_tlvs_find_alloc_asla isisd/isis_tlvs.c:8500 > #3 0x55ce7072fae0 in isis_link_params_update_asla isisd/isis_te.c:191 > FRRouting#4 0x55ce70733881 in isis_link_params_update isisd/isis_te.c:499 > FRRouting#5 0x55ce70693f2a in isis_circuit_up isisd/isis_circuit.c:776 > FRRouting#6 0x55ce7069a120 in isis_csm_state_change isisd/isis_csm.c:135 > FRRouting#7 0x55ce7068dd80 in isis_circuit_enable isisd/isis_circuit.c:79 > FRRouting#8 0x55ce70699346 in isis_ifp_create isisd/isis_circuit.c:1618 > FRRouting#9 0x7fdfcb81f47f in hook_call_if_real lib/if.c:55 > FRRouting#10 0x7fdfcb82056e in if_new_via_zapi lib/if.c:188 > FRRouting#11 0x7fdfcb9d17da in zclient_interface_add lib/zclient.c:2706 > FRRouting#12 0x7fdfcb9df842 in zclient_read lib/zclient.c:4843 > FRRouting#13 0x7fdfcb97798e in event_call lib/event.c:2011 > FRRouting#14 0x7fdfcb842ff1 in frr_run lib/libfrr.c:1216 > FRRouting#15 0x55ce7067cbf2 in main isisd/isis_main.c:360 > FRRouting#16 0x7fdfcb229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 8 byte(s) in 1 object(s) allocated from: > #0 0x7fdfcbeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fdfcb86f8dd in qcalloc lib/memory.c:105 > #2 0x7fdfcb79a7b7 in admin_group_init lib/admin_group.c:186 > #3 0x55ce707739ca in isis_tlvs_find_alloc_asla isisd/isis_tlvs.c:8501 > FRRouting#4 0x55ce7072fae0 in isis_link_params_update_asla isisd/isis_te.c:191 > FRRouting#5 0x55ce70733881 in isis_link_params_update isisd/isis_te.c:499 > FRRouting#6 0x55ce70693f2a in isis_circuit_up isisd/isis_circuit.c:776 > FRRouting#7 0x55ce7069a120 in isis_csm_state_change isisd/isis_csm.c:135 > FRRouting#8 0x55ce7068dd80 in isis_circuit_enable isisd/isis_circuit.c:79 > FRRouting#9 0x55ce70699346 in isis_ifp_create isisd/isis_circuit.c:1618 > FRRouting#10 0x7fdfcb81f47f in hook_call_if_real lib/if.c:55 > FRRouting#11 0x7fdfcb82056e in if_new_via_zapi lib/if.c:188 > FRRouting#12 0x7fdfcb9d17da in zclient_interface_add lib/zclient.c:2706 > FRRouting#13 0x7fdfcb9df842 in zclient_read lib/zclient.c:4843 > FRRouting#14 0x7fdfcb97798e in event_call lib/event.c:2011 > FRRouting#15 0x7fdfcb842ff1 in frr_run lib/libfrr.c:1216 > FRRouting#16 0x55ce7067cbf2 in main isisd/isis_main.c:360 > FRRouting#17 0x7fdfcb229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 PR: 95719 Fixes: 5749ac8 ("isisd: add ASLA support") Signed-off-by: Louis Scalbert <[email protected]>

Seen with bfd_vrf_topo1 on Ubuntu 22.04 hwe. > ==616172==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000ae3a4 at pc 0x556cdc178d8f bp 0x7ffe4f41ace0 sp 0x7ffe4f41acd0 > READ of size 4 at 0x6160000ae3a4 thread T0 > #0 0x556cdc178d8e in ctx_info_from_zns zebra/zebra_dplane.c:3394 > #1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410 > #2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759 > #3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566 > FRRouting#4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793 > FRRouting#5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484 > FRRouting#6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804 > FRRouting#7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456 > FRRouting#8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633 > FRRouting#9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049 > FRRouting#10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903 > FRRouting#11 0x7fb25c173144 in route_node_free lib/table.c:75 > FRRouting#12 0x7fb25c17337f in route_table_free lib/table.c:111 > FRRouting#13 0x7fb25c172fe4 in route_table_finish lib/table.c:46 > FRRouting#14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243 > FRRouting#16 0x556cdc10638b in zebra_finalize zebra/main.c:240 > FRRouting#17 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#19 0x556cdc106deb in main zebra/main.c:543 > FRRouting#20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x556cdc0c7ed4 in _start (/usr/lib/frr/zebra+0x192ed4) > > 0x6160000ae3a4 is located 36 bytes inside of 592-byte region [0x6160000ae380,0x6160000ae5d0) > freed by thread T0 here: > #0 0x7fb25c6b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7fb25c0790e3 in qfree lib/memory.c:131 > #2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261 > #3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319 > FRRouting#4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343 > FRRouting#5 0x7fb25c197443 in vrf_delete lib/vrf.c:282 > FRRouting#6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601 > FRRouting#7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394 > FRRouting#8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609 > FRRouting#9 0x556cdc106345 in zebra_finalize zebra/main.c:223 > FRRouting#10 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#12 0x556cdc106deb in main zebra/main.c:543 > FRRouting#13 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7fb25c6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fb25c078f91 in qcalloc lib/memory.c:106 > #2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231 > #3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429 > FRRouting#4 0x556cdc106cec in main zebra/main.c:480 > FRRouting#5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns Signed-off-by: Louis Scalbert <[email protected]>

We are obviously doing deleting on wrong object. > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105 > #2 0x7fcf7124401a in list_new lib/linklist.c:49 > #3 0x55771621d86d in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1015 > FRRouting#4 0x7fcf71217d79 in hash_get lib/hash.c:147 > FRRouting#5 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030 > FRRouting#6 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131 > FRRouting#7 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424 > FRRouting#8 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521 > FRRouting#9 0x7fcf7137798e in event_call lib/event.c:2011 > FRRouting#10 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216 > FRRouting#11 0x5577160e4d6d in main zebra/main.c:540 > FRRouting#12 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 24 byte(s) in 1 object(s) allocated from: > #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105 > #2 0x7fcf71244129 in listnode_new lib/linklist.c:71 > #3 0x7fcf71244238 in listnode_add lib/linklist.c:92 > FRRouting#4 0x55771621d938 in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1019 > FRRouting#5 0x7fcf71217d79 in hash_get lib/hash.c:147 > FRRouting#6 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030 > FRRouting#7 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131 > FRRouting#8 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424 > FRRouting#9 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521 > FRRouting#10 0x7fcf7137798e in event_call lib/event.c:2011 > FRRouting#11 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216 > FRRouting#12 0x5577160e4d6d in main zebra/main.c:540 > FRRouting#13 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: f80ec7e ("zebra: handle iptable list of interfaces") Signed-off-by: Louis Scalbert <[email protected]> (cherry picked from commit d65d08a00c9a64909092831047305671a8c592c3) Signed-off-by: Louis Scalbert <[email protected]>

We are obviously doing deleting on wrong object. > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105 > #2 0x7fcf7124401a in list_new lib/linklist.c:49 > #3 0x55771621d86d in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1015 > FRRouting#4 0x7fcf71217d79 in hash_get lib/hash.c:147 > FRRouting#5 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030 > FRRouting#6 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131 > FRRouting#7 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424 > FRRouting#8 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521 > FRRouting#9 0x7fcf7137798e in event_call lib/event.c:2011 > FRRouting#10 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216 > FRRouting#11 0x5577160e4d6d in main zebra/main.c:540 > FRRouting#12 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 24 byte(s) in 1 object(s) allocated from: > #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105 > #2 0x7fcf71244129 in listnode_new lib/linklist.c:71 > #3 0x7fcf71244238 in listnode_add lib/linklist.c:92 > FRRouting#4 0x55771621d938 in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1019 > FRRouting#5 0x7fcf71217d79 in hash_get lib/hash.c:147 > FRRouting#6 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030 > FRRouting#7 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131 > FRRouting#8 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424 > FRRouting#9 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521 > FRRouting#10 0x7fcf7137798e in event_call lib/event.c:2011 > FRRouting#11 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216 > FRRouting#12 0x5577160e4d6d in main zebra/main.c:540 > FRRouting#13 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: f80ec7e ("zebra: handle iptable list of interfaces") Signed-off-by: Louis Scalbert <[email protected]>

> ==238132==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 160 byte(s) in 1 object(s) allocated from: > #0 0x7fd79f0b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd79ea6f8dd in qcalloc lib/memory.c:105 > #2 0x5586b26995f9 in bgp_pbr_match_entry_alloc_intern bgpd/bgp_pbr.c:1155 > #3 0x7fd79ea17d79 in hash_get lib/hash.c:147 > FRRouting#4 0x5586b26a551d in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2522 > FRRouting#5 0x5586b26a6436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672 > FRRouting#6 0x5586b26a8089 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2876 > FRRouting#7 0x5586b26a8912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939 > FRRouting#8 0x5586b2829472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#9 0x5586b282ab4b in bgp_zebra_announce_table bgpd/bgp_zebra.c:1766 > FRRouting#10 0x5586b2824b99 in bgp_zebra_tm_connect bgpd/bgp_zebra.c:1091 > FRRouting#11 0x7fd79eb7798e in event_call lib/event.c:2011 > FRRouting#12 0x7fd79ea42ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x5586b2503a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd79e429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.") Signed-off-by: Louis Scalbert <[email protected]>

> Direct leak of 1144 byte(s) in 13 object(s) allocated from: > #0 0x7f3eedeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f3eed86f8dd in qcalloc lib/memory.c:105 > #2 0x55b32d236faf in bgp_pbr_match_alloc_intern bgpd/bgp_pbr.c:1074 > #3 0x7f3eed817d79 in hash_get lib/hash.c:147 > FRRouting#4 0x55b32d242d9a in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2486 > FRRouting#5 0x55b32d244436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672 > FRRouting#6 0x55b32d245a05 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2843 > FRRouting#7 0x55b32d246912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939 > FRRouting#8 0x55b32d3c7472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#9 0x55b32d26e5e7 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#10 0x55b32d26f77d in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#11 0x55b32d2701ff in process_subq bgpd/bgp_route.c:3955 > FRRouting#12 0x55b32d27029f in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#13 0x7f3eed99fdd8 in work_queue_run lib/workqueue.c:282 > FRRouting#14 0x7f3eed97798e in event_call lib/event.c:2011 > FRRouting#15 0x7f3eed842ff1 in frr_run lib/libfrr.c:1216 > FRRouting#16 0x55b32d0a1a15 in main bgpd/bgp_main.c:545 > FRRouting#17 0x7f3eed229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.") Signed-off-by: Louis Scalbert <[email protected]>

Note that bgp_pbr_policyroute_add_from_zebra() and bgp_pbr_policyroute_remove_from_zebra() are only called from bgp_pbr_handle_entry(). > ==966967==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x7fd44744401a in list_new lib/linklist.c:49 > #3 0x560f8c094490 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2818 > FRRouting#4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#11 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x7fd44744401a in list_new lib/linklist.c:49 > #3 0x560f8c09439d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2812 > FRRouting#4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#11 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362 > #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400 > FRRouting#4 0x560f8c094530 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2819 > FRRouting#5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#12 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#14 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362 > #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400 > FRRouting#4 0x560f8c09443d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2813 > FRRouting#5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#12 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#14 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Louis Scalbert <[email protected]>

Seen with bfd_vrf_topo1 on Ubuntu 22.04 hwe. Do not call ns_delete() from zebra_vrf_delete(), which calls zebra_ns_delete(). - If a netns is removed from the system, vrf_delete()->zebra_vrf_delete() is called before calling ns_delete() (see zebra_ns_notify.c). - If zebra is terminating, zebra_ns_final_shutdown() will call zebra_vrf_delete(). > ==616172==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000ae3a4 at pc 0x556cdc178d8f bp 0x7ffe4f41ace0 sp 0x7ffe4f41acd0 > READ of size 4 at 0x6160000ae3a4 thread T0 > #0 0x556cdc178d8e in ctx_info_from_zns zebra/zebra_dplane.c:3394 > #1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410 > #2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759 > #3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566 > FRRouting#4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793 > FRRouting#5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484 > FRRouting#6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804 > FRRouting#7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456 > FRRouting#8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633 > FRRouting#9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049 > FRRouting#10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903 > FRRouting#11 0x7fb25c173144 in route_node_free lib/table.c:75 > FRRouting#12 0x7fb25c17337f in route_table_free lib/table.c:111 > FRRouting#13 0x7fb25c172fe4 in route_table_finish lib/table.c:46 > FRRouting#14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243 > FRRouting#16 0x556cdc10638b in zebra_finalize zebra/main.c:240 > FRRouting#17 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#19 0x556cdc106deb in main zebra/main.c:543 > FRRouting#20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x556cdc0c7ed4 in _start (/usr/lib/frr/zebra+0x192ed4) > > 0x6160000ae3a4 is located 36 bytes inside of 592-byte region [0x6160000ae380,0x6160000ae5d0) > freed by thread T0 here: > #0 0x7fb25c6b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7fb25c0790e3 in qfree lib/memory.c:131 > #2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261 > #3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319 > FRRouting#4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343 > FRRouting#5 0x7fb25c197443 in vrf_delete lib/vrf.c:282 > FRRouting#6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601 > FRRouting#7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394 > FRRouting#8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609 > FRRouting#9 0x556cdc106345 in zebra_finalize zebra/main.c:223 > FRRouting#10 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#12 0x556cdc106deb in main zebra/main.c:543 > FRRouting#13 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7fb25c6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fb25c078f91 in qcalloc lib/memory.c:106 > #2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231 > #3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429 > FRRouting#4 0x556cdc106cec in main zebra/main.c:480 > FRRouting#5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns Signed-off-by: Louis Scalbert <[email protected]>

Seen with isis_srv6_topo1 topotest. > ==178793==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 56 byte(s) in 1 object(s) allocated from: > #0 0x7f3f63cb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f3f6366f8dd in qcalloc lib/memory.c:105 > #2 0x561b810c62b7 in isis_srv6_sid_alloc isisd/isis_srv6.c:243 > #3 0x561b8111f944 in isis_zebra_srv6_sid_notify isisd/isis_zebra.c:1534 > FRRouting#4 0x7f3f637df9d7 in zclient_read lib/zclient.c:4845 > FRRouting#5 0x7f3f637779b2 in event_call lib/event.c:2011 > FRRouting#6 0x7f3f63642ff1 in frr_run lib/libfrr.c:1216 > FRRouting#7 0x561b81018bf2 in main isisd/isis_main.c:360 > FRRouting#8 0x7f3f63029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: 0af0f46 ("isisd: Receive SRv6 SIDs notifications from zebra") Signed-off-by: Louis Scalbert <[email protected]>

A heap use after free when enabling bmp mirror on a non connected BMP target. > Apr 22 14:06:49 vRR-DUT systemd[1]: Started bfdd. > Apr 22 14:06:51 vRR-DUT bgpd[1522]: [VTCF0-ZHP6C] bmp: missing TX OPEN message for peer Static announcement > Apr 22 14:06:51 vRR-DUT bgpd[1522]: [K3RM9-4A4HY] bmp: missing RX OPEN message for peer Static announcement > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ================================================================= > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ==1522==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000321d0 at pc 0x7fe7f11c548e bp 0x7fff49f80d40 sp 0x7fff49f80d30 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: READ of size 8 at 0x60f0000321d0 thread T0 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f11c548d in typesafe_list_add /build/make-pkg/output/_packages/cp-routing/src/lib/typesafe.h:161 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f11c9347 in bmp_mirrorq_add_tail /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:116 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11d030f in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:867 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#9 0x7fe7f4c29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#10 0x55c756c6e384 in _start (/usr/bin/bgpd+0x272384) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x60f0000321d0 is located 0 bytes inside of 162-byte region [0x60f0000321d0,0x60f000032272) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: freed by thread T0 here: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f58b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f526f918 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f918) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11d057b in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:875 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: previously allocated by thread T0 here: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f58b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f526f7c6 in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7c6) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11cfd38 in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:835 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: SUMMARY: AddressSanitizer: heap-use-after-free /build/make-pkg/output/_packages/cp-routing/src/lib/typesafe.h:161 in typesafe_list_add > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow bytes around the buggy address: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe3f0: 00 00 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe410: 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: =>0x0c1e7fffe430: 00 fa fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe470: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow byte legend (one shadow byte represents 8 application bytes): > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Addressable: 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Partially addressable: 01 02 03 04 05 06 07 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Heap left redzone: fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Freed heap region: fd > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack left redzone: f1 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack mid redzone: f2 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack right redzone: f3 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack after return: f5 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack use after scope: f8 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Global redzone: f9 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Global init order: f6 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Poisoned by user: f7 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Container overflow: fc > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Array cookie: ac > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Intra object redzone: bb > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ASan internal: fe > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Left alloca redzone: ca > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Right alloca redzone: cb > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow gap: cc > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ==1522==ABORTING > Apr 22 14:06:52 vRR-DUT yams[449]: CONFIG: [{'name': 'ttyS0'}] > Apr 22 14:06:52 vRR-DUT zebra[652]: [GE156-FS0MJ][EC 100663299] stream_read_try: read failed on fd 50: Connection reset by peer > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Main process exited, code=exited, status=1/FAILURE > Apr 22 14:06:52 vRR-DUT zebra[652]: [GE156-FS0MJ][EC 100663299] stream_read_try: read failed on fd 39: Connection reset by peer > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Failed with result 'exit-code'. > Apr 22 14:06:52 vRR-DUT zebra[652]: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 0) encountered an error and is shutting down. > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Consumed 2.361s CPU time. > Apr 22 14:06:52 vRR-DUT zebra[652]: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 1) encountered an error and is shutting down. > Apr 22 14:06:52 vRR-DUT zebra[652]: [JPSA8-5KYEA] client 39 disconnected 0 bgp routes removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [S929C-NZR3N] client 39 disconnected 0 bgp nhgs removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [KQB7H-NPVW9] /build/make-pkg/output/_packages/cp-routing/src/zebra/zebra_ptm.c:1285 failed to find process pid registration > Apr 22 14:06:52 vRR-DUT zebra[652]: [JPSA8-5KYEA] client 50 disconnected 0 bgp routes removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [S929C-NZR3N] client 50 disconnected 0 bgp nhgs removed from the rib > Do not enqueue item in the mirror queue if no reference count has been found in the connection list. Fixes: b1ebe54 ("bgpd: bmp, handle imported bgp instances in bmp_mirror") Signed-off-by: Philippe Guibert <[email protected]>

slankdev and others added 17 commits September 12, 2022 11:07

lib: add copy function for bitfield_t

34aac02

Add a function to copy a bitfield_t structure. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

lib: add a function to print flex-algo metric-type

7fe58a5

Add a function to returns a human readable string of the metric types that are defined in yang. Signed-off-by: Louis Scalbert <[email protected]>

github-actions bot added the master label Sep 12, 2022

louis-6wind force-pushed the flexalgo-mpls-frrbot2 branch from 7d23c15 to dd4f50b Compare September 12, 2022 16:38

louis-6wind and others added 4 commits September 12, 2022 18:44

isisd: dummy frrbot

5fd879a

Signed-off-by: Louis Scalbert <[email protected]>

isisd: dummy frrbot

74804c3

Signed-off-by: Louis Scalbert <[email protected]>

isisd: add isis flex-algo configuration backend

cdcdf50

Add the backend functions for the flex-algo configuration. Signed-off-by: Hiroki Shirokura <[email protected]> Signed-off-by: Eric Kinzie <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>

louis-6wind force-pushed the flexalgo-mpls-frrbot2 branch from dd4f50b to cdcdf50 Compare September 12, 2022 16:45

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Flexalgo mpls frrbot2 #2

Flexalgo mpls frrbot2 #2

louis-6wind commented Sep 12, 2022

Flexalgo mpls frrbot2 #2

Are you sure you want to change the base?

Flexalgo mpls frrbot2 #2

Conversation

louis-6wind commented Sep 12, 2022