Skip to content

Conversation

louis-6wind
Copy link
Owner

No description provided.

slankdev and others added 17 commits September 12, 2022 11:07
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a function to copy a bitfield_t structure.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a function to returns a human readable string of the metric types
that are defined in yang.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind and others added 4 commits September 12, 2022 18:44
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the backend functions for the flex-algo configuration.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the frontend functions for the flex-algo configuration.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Deal with the packing and unpacking of following Flex-Algo
(Sub-)-Sub-TLVs:

- Router Capability (already defined TLV 242)
	- List of the Flex-Algo Definitions (Sub-TLV 26)
		- Exclude admin group (Sub-Sub-TLV 1)
                - Include-any admin group (Sub-Sub-TLV 2)
                - Include-all admin group (Sub-Sub-TLV 3)
                - Flags (for prefix-metric) (Sub-Sub-TLV 4)
- Extended IS Reachability (already defined TLV 22)
	- Application-Specific Link Attributes (Sub-TLV 16)
	  (to enable the Flex-Algo flag on a link)
		- Admin-group (Sub-Sub-TLV 3)
		- Extended Admin-group (Sub-Sub-TLV 14)

Not that:

- Admin-group deals with affinities.
- List of SR Algorithm (Sub-TLV 19) within Router Capability (TLV 242)
  are already set in a previous commit.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Take into account the flex-algo affinity constraints to compute the SPF
tree.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Create a temporary "merge" route table that contains the routing
information from all algorithms and install the merge route table
into the FIB.

Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Feb 14, 2025
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 <louis.scalbert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Feb 27, 2025
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 <philippe.guibert@6wind.com>
(cherry picked from commit 7ae70eb)
louis-6wind added a commit that referenced this pull request Feb 27, 2025
Fix the display of the local label in show bgp.

> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
>   Advertised to non peer-group peers:
>  192.168.1.2
>  65501
>    192.168.1.2 from 192.168.1.2 (172.16.2.2)
>      Origin IGP, metric 0, valid, external, best (First path received)
>      Remote label: 3
>      Last update: Fri Oct 25 17:55:45 2024

Fixes: 67f67ba ("bgpd: Drop label_ntop/label_pton functions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e7b3276)
louis-6wind pushed a commit that referenced this pull request Feb 27, 2025
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 <philippe.guibert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Mar 5, 2025
On a L3VPN setup, an aggretated prefix can not be exported and selected.
The below example illustrates the 172.31.0.0/24 aggregated prefix, which
is valid as a VRF prefix, but invalid as a VPN prefix:

> r1# show bgp ipv4 vpn 172.31.0.0/24
> BGP routing table entry for 444:1:172.31.0.0/24, version 0
> not allocated
> Paths: (1 available, no best path)
>   Not advertised to any peer
>   Local, (aggregated by 65500 192.0.2.1)
>     0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf vrf1(4) announce-nh-self
>       Origin incomplete, metric 0, weight 32768, invalid, sourced,
local, atomic-aggregate
>       Extended Community: RT:52:100
>       Originator: 192.0.2.1
>       Remote label: 101
>       Last update: Mon Mar  3 14:35:04 2025
> r1# show bgp vrf vrf1 ipv4 172.31.0.0/24
> BGP routing table entry for 172.31.0.0/24, version 1
> Paths: (1 available, best #1, vrf vrf1)
>   Not advertised to any peer
>   Local, (aggregated by 65500 192.0.2.1)
>     0.0.0.0 from 0.0.0.0 (192.0.2.1)
>       Origin incomplete, metric 0, weight 32768, valid, aggregated,
local, atomic-aggregate, best (First path received)
>       Last update: Mon Mar  3 14:35:03 2025
> r1#

Actually, the aggregated prefix nexthop is considered, and 0.0.0.0 is
an invalid nexthop.

> r1# show bgp vrf vrf1 nexthop
> Current BGP nexthop cache:
>  0.0.0.0 invalid, #paths 1
>   Is not Registered
>   Last update: Thu Feb 13 18:33:43 2025

Fix this by considering the L3VPN prefix selected, if the VRF prefix
is selected too.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind added a commit that referenced this pull request Mar 5, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Mar 10, 2025
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 <louis.scalbert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Mar 14, 2025
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 <rvaratharaj@nvidia.com>
louis-6wind pushed a commit that referenced this pull request Mar 14, 2025
The command `show bgp <afi> <safi>` has this output:

r1# show bgp ipv4 uni 10.0.0.0
BGP routing table entry for 10.0.0.0/32, version 1
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  r1-eth0 r1-eth1 r1-eth2 r1-eth3
  ....

It specifically states `Advertised to non peer-group peers:` yet
the code is not filtering those out.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
louis-6wind added a commit that referenced this pull request Apr 11, 2025
> ==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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 11, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 11, 2025
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 <louis.scalbert@6wind.com>
(cherry picked from commit d65d08a00c9a64909092831047305671a8c592c3)
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 11, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 11, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 14, 2025
> ==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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 14, 2025
> 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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 14, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 14, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 16, 2025
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 <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Apr 22, 2025
Fix the display of the local label in show bgp.

> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
>   Advertised to non peer-group peers:
>  192.168.1.2
>  65501
>    192.168.1.2 from 192.168.1.2 (172.16.2.2)
>      Origin IGP, metric 0, valid, external, best (First path received)
>      Remote label: 3
>      Last update: Fri Oct 25 17:55:45 2024

Fixes: 67f67ba ("bgpd: Drop label_ntop/label_pton functions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e7b3276)
louis-6wind pushed a commit that referenced this pull request May 12, 2025
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 <philippe.guibert@6wind.com>
vjardin pushed a commit that referenced this pull request May 18, 2025
Issue:
When we have bgp peer-group, and prefix are advertised to the
peers in it correctly, it still shows Not advertised to any peer

Fix:
1)Rearranged code, to show 1st non peer-group advertised state
2)Then show peer-group peers

Testing:
router bgp 1001
 no bgp ebgp-requires-policy
 read-quanta 1
 timers bgp 5 60
 neighbor nbr_grp1 peer-group
 neighbor nbr_grp1 remote-as external
 neighbor nbr_grp2 peer-group
 neighbor nbr_grp2 remote-as external
 neighbor nbr_grp3 peer-group
 neighbor nbr_grp3 remote-as external
 neighbor 2001:db8:2:252::2 peer-group nbr_grp1
 neighbor 2001:db8:2:254::2 peer-group nbr_grp1
 neighbor 2001:db8:2:255::2 peer-group nbr_grp1
 neighbor 2001:db8:2:253::2 peer-group nbr_grp2
 neighbor 2001:db8:3:1::2 peer-group nbr_grp2
 neighbor 2001:db8:3:2::2 peer-group nbr_grp3
 neighbor 2001:db8:3:3::2 peer-group nbr_grp3
 neighbor 2001:db8:3:4::2 peer-group nbr_grp3
 neighbor 2001:db8:1:1::2 remote-as external
 !
 address-family ipv6 unicast
  redistribute sharp
  neighbor nbr_grp1 activate
  neighbor nbr_grp2 activate
  neighbor nbr_grp3 activate
  neighbor 2001:db8:1:1::2 activate
 exit-address-family
exit
!
end

 sh bgp ipv6 unicast
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 1001
Status codes:  s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2100:cafe::/128  2001:db8::1              0         32768 ?

Displayed 1 routes and 1 total paths
r1# sh bgp ipv6 unicast  2100:cafe::/128
BGP routing table entry for 2100:cafe::/128, version 1
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  2001:db8:1:1::2

  Advertised to peer-group nbr_grp1 peers:
  2001:db8:2:252::2 2001:db8:2:254::2 2001:db8:2:255::2

  Advertised to peer-group nbr_grp2 peers:
  2001:db8:2:253::2 2001:db8:3:1::2

  Advertised to peer-group nbr_grp3 peers:
  2001:db8:3:2::2 2001:db8:3:3::2 2001:db8:3:4::2

  Local
    2001:db8::1 from :: (192.168.1.1)
      Origin incomplete, metric 0, weight 32768, valid, sourced, best (First path received)
      Last update: Sat Apr  5 20:29:31 2025

1# sh bgp ipv6 unicast  2100:cafe::/128 json
{
  "prefix":"2100:cafe::/128",
  "version":1,
  "advertisedTo":{
    "2001:db8:1:1::2":{
      "hostname":"r2"
    },
    "2001:db8:2:252::2":{
      "hostname":"r2"
    },
    "2001:db8:2:254::2":{
      "hostname":"r2"
    },
    "2001:db8:2:255::2":{
      "hostname":"r2"
    },
    "2001:db8:2:253::2":{
      "hostname":"r2"
    },
    "2001:db8:3:1::2":{
      "hostname":"r2"
    },
    "2001:db8:3:2::2":{
      "hostname":"r2"
    },
    "2001:db8:3:3::2":{
      "hostname":"r2"
    },
    "2001:db8:3:4::2":{
      "hostname":"r2"
    }
  },
  "paths":[
    {
      "aspath":{
        "string":"Local",
        "segments":[
        ],
        "length":0
      },
      "origin":"incomplete",
      "metric":0,
      "weight":32768,
      "valid":true,
      "version":1,
      "sourced":true,
      "bestpath":{
        "overall":true,
        "selectionReason":"First path received"
      },
      "lastUpdate":{
        "epoch":1743884971,
        "string":"Sat Apr  5 20:29:31 2025"
      },
      "fibInstalled":true,
      "nexthops":[
        {
          "ip":"2001:db8::1",
          "hostname":"r1",
          "afi":"ipv6",
          "scope":"global",
          "linkLocalOnly":false,
          "length":16,
          "metric":0,
          "accessible":true,
          "used":true
        }
      ],
      "peer":{
        "peerId":"::",
        "routerId":"192.168.1.1"
      }
    }
  ]
}
r1#

Signed-off-by: Soumya Roy <souroy@nvidia.com>
vjardin pushed a commit that referenced this pull request May 18, 2025
Currently peer group name is not displayed in show bgp
vty output and also in json output. This fix adds those
information in show bgp command

test:

BGP routing table entry for 192.168.251.0/30, version 1
Paths: (1 available, best #1, table default)
  Advertised to peers:
  192.168.255.3 192.168.251.2 192.168.252.2 r1-eth0
  Local
    0.0.0.0 from 0.0.0.0 (192.168.255.1)
      Origin incomplete, metric 0, weight 32768, valid, sourced, best (First path received)
      Last update: Tue Apr 29 17:28:02 2025

BGP advertisement output json:
{
  "prefix":"192.168.251.0/30",
  "version":1,
  "advertisedTo":{
    "192.168.255.3":{
      "hostname":"r3",
      "peerGroup":"PG"
    },
    "192.168.251.2":{
      "hostname":"r2",
      "peerGroup":"PG2"
    },
    "192.168.252.2":{
      "hostname":"r4",
      "peerGroup":"PG2"
    },
    "r1-eth0":{
      "hostname":"r2"
    }
  },
  "paths":[
    {
      "aspath":{
        "string":"Local",
        "segments":[
        ],
        "length":0
      },
      "origin":"incomplete",
      "metric":0,
      "weight":32768,
      "valid":true,
      "version":1,
      "sourced":true,
      "bestpath":{
        "overall":true,
        "selectionReason":"First path received"
      },
      "lastUpdate":{
        "epoch":1744926043,
        "string":"Thu Apr 17 21:40:43 2025"
      },
      "fibInstalled":true,
      "nexthops":[
        {
          "ip":"0.0.0.0",
          "hostname":"r1",
          "afi":"ipv4",
          "metric":0,
          "accessible":true,
          "used":true
        }
      ],
      "peer":{
        "peerId":"0.0.0.0",
        "routerId":"192.168.255.1"
      }
    }
  ]
}

Signed-off-by: Soumya Roy <souroy@nvidia.com>
vjardin pushed a commit that referenced this pull request May 18, 2025
The following crash has been seen:

> #0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007f48a576db78 in core_handler (signo=11, siginfo=0x7ffeee4f2b30, context=0x7ffeee4f2a00) at lib/sigevent.c:262
> #2  <signal handler called>
> #3  0x000055aded0d793a in isis_spf_process_lsp (spftree=0x55adee945120, lsp=0x55adee971800, cost=3, depth=1, root_sysid=0x55adee9451ac "", parent=0x55adee9474c0) at isisd/isis_spf.c:887
> FRRouting#4  0x000055aded0d9bd1 in isis_spf_loop (spftree=0x55adee945120, root_sysid=0x55adee9451ac "") at isisd/isis_spf.c:1679
> FRRouting#5  0x000055aded0d9fd1 in isis_run_spf (spftree=0x55adee945120) at isisd/isis_spf.c:1798
> FRRouting#6  0x000055aded0bad65 in isis_spf_run_neighbors (spftree=0x55adee962220) at isisd/isis_lfa.c:1259
> FRRouting#7  0x000055aded0bd896 in isis_spf_run_lfa (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_lfa.c:2291
> FRRouting#8  0x000055aded0da0f2 in isis_run_spf_with_protection (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_spf.c:1817
> FRRouting#9  0x000055aded0da350 in isis_run_spf_cb (thread=0x7ffeee4f3330) at isisd/isis_spf.c:1870
> FRRouting#10 0x00007f48a5786dcc in thread_call (thread=0x7ffeee4f3330) at lib/thread.c:2002
> FRRouting#11 0x00007f48a57213ee in frr_run (master=0x55adee6cdb40) at lib/libfrr.c:1196
> FRRouting#12 0x000055aded0acda2 in main (argc=2, argv=0x7ffeee4f3548, envp=0x7ffeee4f3560) at isisd/isis_main.c:273

It is caused by an attempt to access lsp->tlvs in isis_spf_process_lsp()
label lspfragloop when lsp is NULL. isis_spf_process_lsp() checks that
the lsp pointer is not NULL at the function beginning but af8ac8f
("isisd: send/receive LSPs with new parser") has introduced some
lsp->tlvs accesses after the lspfragloop label without checking that lsp
is not NULL.

The crash has been seen in the following situation:
- ISIS is configured to import routes from BGP
- ISIS classic LFA is enabled on all ISIS interfaces
- BGP receives routes from an exabgp peers
- exabgp is stopped in the middle while sending new prefixes

The same situation without LFA does not trigger the bug. However, it
seems that the crash can potentially happen without LFA.

Fixes: af8ac8f ("isisd: send/receive LSPs with new parser")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind added a commit that referenced this pull request Jul 2, 2025
Seen with bfd_vrf_topo1, and bgp_evpn_rt5 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 <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Jul 2, 2025
A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> FRRouting#4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> FRRouting#5  <signal handler called>
> FRRouting#6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> FRRouting#7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> FRRouting#8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> FRRouting#9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> FRRouting#10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> FRRouting#11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> FRRouting#12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> FRRouting#13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> FRRouting#14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Jul 2, 2025
issue detected by Address Sanitizer Error :

Address Sanitizer Error detected in /tmp_topotests/bgp_listen_l3vrf.test_bgp_listen_l3vrf/r1.asan.bgpd.6703

=================================================================
==6703==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x7f34c28b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f34c241b45a in qcalloc lib/memory.c:111
    #2 0x7f34c247b1da in prefix_new lib/prefix.c:1192
    #3 0x55e0992e2041 in peer_group_listen_range_add bgpd/bgpd.c:3258
    FRRouting#4 0x55e099282694 in bgp_listen_range bgpd/bgp_vty.c:4848
    FRRouting#5 0x7f34c2397bc0 in cmd_execute_command_real lib/command.c:1011
    FRRouting#6 0x7f34c2397edf in cmd_execute_command lib/command.c:1070
    FRRouting#7 0x7f34c239840b in cmd_execute lib/command.c:1236
    FRRouting#8 0x7f34c24e204e in vty_command lib/vty.c:626
    FRRouting#9 0x7f34c24e259b in vty_execute lib/vty.c:1389
    FRRouting#10 0x7f34c24e5f97 in vtysh_read lib/vty.c:2408
    FRRouting#11 0x7f34c24d2958 in event_call lib/event.c:2005
    FRRouting#12 0x7f34c23fc4e0 in frr_run lib/libfrr.c:1247
    FRRouting#13 0x55e0990949ff in main bgpd/bgp_main.c:565
    FRRouting#14 0x7f34c1e2c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 1 allocation(s).
***********************************************************************************

Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
louis-6wind pushed a commit that referenced this pull request Jul 16, 2025
The sub sub tlv options of the srv6 prefix sid option is partially
visible hen compiling with enable-bgp-vnc, but not in json neither in
other parts of the code.

> # show bgp ipv6 vpn
> [..]
>  *>  2001:db9:10::/64 ::@8<                    0         32768 ?
>    UN=:: EC{99:99} label=3 sid=fc05:0:5:cece:2345:: sid_structure=[32,16,32,0] type=bgp, subtype=5

> # show bgp ipv6 vpn detail json
> [..]
> ,"2001:db9:10::/64": [{"aspath":{"string":"Local","segments":[],"length":0},"nhVrfName":"vrf10","nhVrfId":8,
> "announceNexthopSelf":true,"origin":"incomplete","metric":0,"weight":32768,"valid":true,"version":1,"sourced":true,
> "local":true,"bestpath":{"overall":true,"selectionReason":"First path received"},"extendedCommunity":{"string":"RT:99:99"},
> "originatorId":"5.5.5.5","remoteLabel":3,"	id":"fc05:0:5:cece:2345::",
> "lastUpdate":{"epoch":1751440457,"string":"Wed Jul  2 09:14:17 2025"},
> "nexthops":[{"ip":"::","hostname":"rt5","afi":"ipv6","scope":"global",
> "linkLocalOnly":false,"length":16,"metric":0,"accessible":true,"used":true}],
> "peer":{"peerId":"::","routerId":"5.5.5.5"}}]

Add json attributes to display the attribute values in a
remoteSidStructure entry.
Display the attribute values in a show command with detailed
information.

> rt5# show bgp ipv6 vpn 2001:db9:10::/64
> BGP routing table entry for 5:10:2001:db9:10::/64, version 2
> not allocated
> Paths: (1 available, best #1)
>   Advertised to peers:
>   fc00:0:1::1
>   Local
>     :: from :: (5.5.5.5) vrf vrf10(8) announce-nh-self
>       Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received)
>       Extended Community: RT:99:99
>       Originator: 5.5.5.5
>       Remote label: 3
>       Remote SID: fc05:0:5:cece:2345::, sid structure=[32 16 32 0 0 0]
>       Last update: Wed Jul  2 09:53:59 2025

> rt5# show bgp ipv6 vpn detail json
> [..]
>   "remoteSid":"fc05:0:5:cece:2345::",
>   "remoteSidStructure":{
>     "locatorBlockLen":32,
>     "locatorNodeLen":16,
>     "functionLen":32,
>     "argumentLen":0,
>     "transpositionLen":0,
>     "transpositionOffset":0
>   },

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Jul 16, 2025
Memory leak happens when modifying srv6 configuration. Some sid
notifications events will flush a valid srv6 context.

> Direct leak of 736 byte(s) in 2 object(s) allocated from:
>     #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7c112bc3595e in qcalloc lib/memory.c:111
>     #2 0x7c112bc4d37e in srv6_locator_alloc lib/srv6.c:227
>     #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662
>     FRRouting#4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804
>     FRRouting#5 0x7c112bcfaa90 in event_call lib/event.c:2005
>     FRRouting#6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252
>     FRRouting#7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565
>     FRRouting#8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360
>     FRRouting#10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc)
>
> Indirect leak of 80 byte(s) in 2 object(s) allocated from:
>     #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7c112bc3595e in qcalloc lib/memory.c:111
>     #2 0x7c112bc4d396 in srv6_locator_alloc lib/srv6.c:229
>     #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662
>     FRRouting#4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804
>     FRRouting#5 0x7c112bcfaa90 in event_call lib/event.c:2005
>     FRRouting#6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252
>     FRRouting#7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565
>     FRRouting#8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360
>     FRRouting#10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc)

Fixes: 7a2e64e ("bgpd: Receive SRv6 SIDs notification from zebra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind pushed a commit that referenced this pull request Jul 16, 2025
When SRv6 locator is modified for configuration, a memory leak is
observed.

> ==26714==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 1104 byte(s) in 3 object(s) allocated from:
>     #0 0x7fb232cb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7fb232822b79 in qcalloc lib/memory.c:111
>     #2 0x7fb23283a8b6 in srv6_locator_alloc lib/srv6.c:227
>     #3 0x56347cdd4b57 in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3661
>     FRRouting#4 0x7fb23290d03e in zclient_read lib/zclient.c:4804
>     FRRouting#5 0x7fb2328da6a0 in event_call lib/event.c:2005
>     FRRouting#6 0x7fb232800791 in frr_run lib/libfrr.c:1252
>     FRRouting#7 0x56347cb929ff in main bgpd/bgp_main.c:565
>     FRRouting#8 0x7fb23222c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants