]> git.puffer.fish Git - matthieu/frr.git/log
matthieu/frr.git
11 months agoMerge pull request #16064 from FRRouting/mergify/bp/stable/8.4/pr-16032
Donald Sharp [Tue, 21 May 2024 18:46:00 +0000 (14:46 -0400)]
Merge pull request #16064 from FRRouting/mergify/bp/stable/8.4/pr-16032

zebra: Deny the routes if ip protocol CLI refers to an undefined rmap (backport #16032)

11 months agozebra: Deny the routes if ip protocol CLI refers to an undefined rmap
Pooja Jagadeesh Doijode [Thu, 16 May 2024 23:36:18 +0000 (16:36 -0700)]
zebra: Deny the routes if ip protocol CLI refers to an undefined rmap

Currently zebra does not deny the routes if `ip protocol <proto> route-map
FOO`
commmand is configured with reference to an undefined route-map (FOO in
this case).
However, on FRR restart, in zebra_route_map_check() routes get denied
if route-map name is available but the route-map is not defined. This
change was introduced in fd303a4ba14c762550db972317e1e88528768005.

Fix:
When `ip protocol <proto> route-map FOO` CLI is configured with reference to an
undefined route-map FOO, let the processing in ip_protocol_rm_add() and
ip_protocol_rm_del() go through so that zebra can deny the routes instead
of simply returning. This will result in consistent behavior.

Testing Done:

Before fix:
```
spine-1# configure
spine-1(config)# ip protocol bgp route-map rmap7

root@spine-1:mgmt:/var/home/cumulus# vtysh -c "show run" | grep rmap7
ip protocol bgp route-map rmap7
root@spine-1:mgmt:/var/home/cumulus#

spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
       Z - FRR,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

C>* 27.0.0.1/32 is directly connected, lo, 02:27:45
B>* 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1, weight 1, 02:27:35
B>* 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2, weight 1, 02:27:40
B>* 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3, weight 1, 02:27:40
B>* 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4, weight 1, 02:27:40
```

After fix:
```
spine-1(config)# ip protocol bgp route-map route-map67
spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
       Z - FRR,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

C>* 27.0.0.1/32 is directly connected, lo, 00:35:03
B   27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1 inactive, weight 1, 00:34:58
B   27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2 inactive, weight 1, 00:34:57
B   27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3 inactive, weight 1, 00:34:57
B   27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4 inactive, weight 1, 00:34:58
spine-1(config)#

root@spine-1:mgmt:/var/home/cumulus# ip route show
root@spine-1:mgmt:/var/home/cumulus#
```

Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
(cherry picked from commit 705e8ef78f84dea3af5943a74571f968ad076c8d)

11 months agoMerge pull request #15992 from Jafaral/pim-fixes-8.4
Donatas Abraitis [Mon, 13 May 2024 04:56:39 +0000 (07:56 +0300)]
Merge pull request #15992 from Jafaral/pim-fixes-8.4

pimd: fixes split off from #15969 (backport #15975)

11 months agopimd: fix order of operations for evaluating join
David Lamparter [Mon, 12 Dec 2022 16:50:59 +0000 (17:50 +0100)]
pimd: fix order of operations for evaluating join

join_desired looks at whether up->channel_oil is empty.  up->channel_oil
is updated from pim_forward_stop(), calling pim_channel_del_oif().  But
that was being called *after* updating join_desired, so join_desired saw
a non-empty OIL.  Pull up the pim_forward_stop() call to before updating
join_desired.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit fdb1a6fed5a8e42447b5b9633ad9df0f3042d0a9)

11 months agopimd: fix null register before aging out reg-stop
David Lamparter [Mon, 17 Apr 2023 09:47:08 +0000 (11:47 +0200)]
pimd: fix null register before aging out reg-stop

It looks like the code was trying to do this with the null_register
parameter on pim_upstream_start_register_stop_timer(), but that didn't
quite work right.  Restructure a bit to get it right.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit dce38da8061a7ac62c690dbb8a89cae7f9a758d6)

# Conflicts:
# pimd/pim_upstream.c

11 months agopimd: fix dr-priority range
David Lamparter [Fri, 14 Apr 2023 15:17:27 +0000 (17:17 +0200)]
pimd: fix dr-priority range

0 is a valid DR priority.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit b564c1d890aef75067db22df09e608faf72b99f5)

11 months agoMerge pull request #15934 from FRRouting/mergify/bp/stable/8.4/pr-15628
David Lamparter [Mon, 6 May 2024 11:33:18 +0000 (13:33 +0200)]
Merge pull request #15934 from FRRouting/mergify/bp/stable/8.4/pr-15628

CVE-2024-31948

11 months agoMerge pull request #15933 from opensourcerouting/8.4-backport-20240506
David Lamparter [Mon, 6 May 2024 11:32:56 +0000 (13:32 +0200)]
Merge pull request #15933 from opensourcerouting/8.4-backport-20240506

CVE-2023-47234, CVE-2023-47235, and CVE-2024-27913

11 months agobgpd: Prevent from one more CVE triggering this place
Donatas Abraitis [Wed, 27 Mar 2024 17:08:38 +0000 (19:08 +0200)]
bgpd: Prevent from one more CVE triggering this place

If we receive an attribute that is handled by bgp_attr_malformed(), use
treat-as-withdraw behavior for unknown (or missing to add - if new) attributes.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit babb23b74855e23c987a63f8256d24e28c044d07)

11 months agobgpd: Fix error handling when receiving BGP Prefix SID attribute
Donatas Abraitis [Wed, 27 Mar 2024 16:42:56 +0000 (18:42 +0200)]
bgpd: Fix error handling when receiving BGP Prefix SID attribute

Without this patch, we always set the BGP Prefix SID attribute flag without
checking if it's malformed or not. RFC8669 says that this attribute MUST be discarded.

Also, this fixes the bgpd crash when a malformed Prefix SID attribute is received,
with malformed transitive flags and/or TLVs.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ba6a8f1a31e1a88df2de69ea46068e8bd9b97138)

11 months agoospfd: Solved crash in OSPF TE parsing
Olivier Dugeon [Mon, 26 Feb 2024 09:40:34 +0000 (10:40 +0100)]
ospfd: Solved crash in OSPF TE parsing

Iggy Frankovic discovered an ospfd crash when perfomring fuzzing of OSPF LSA
packets. The crash occurs in ospf_te_parse_te() function when attemping to
create corresponding egde from TE Link parameters. If there is no local
address, an edge is created but without any attributes. During parsing, the
function try to access to this attribute fields which has not been created
causing an ospfd crash.

The patch simply check if the te parser has found a valid local address. If not
found, we stop the parser which avoid the crash.

Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit a73e66d07329d721f26f3f336f7735de420b0183)

11 months agobgpd: Ignore handling NLRIs if we received MP_UNREACH_NLRI
Donatas Abraitis [Sun, 29 Oct 2023 20:44:45 +0000 (22:44 +0200)]
bgpd: Ignore handling NLRIs if we received MP_UNREACH_NLRI

If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.

In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.

In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c37119df45bbf4ef713bc10475af2ee06e12f3bf)

11 months agobgpd: Treat EOR as withdrawn to avoid unwanted handling of malformed attrs
Donatas Abraitis [Fri, 27 Oct 2023 08:56:45 +0000 (11:56 +0300)]
bgpd: Treat EOR as withdrawn to avoid unwanted handling of malformed attrs

Treat-as-withdraw, otherwise if we just ignore it, we will pass it to be
processed as a normal UPDATE without mandatory attributes, that could lead
to harmful behavior. In this case, a crash for route-maps with the configuration
such as:

```
router bgp 65001
 no bgp ebgp-requires-policy
 neighbor 127.0.0.1 remote-as external
 neighbor 127.0.0.1 passive
 neighbor 127.0.0.1 ebgp-multihop
 neighbor 127.0.0.1 disable-connected-check
 neighbor 127.0.0.1 update-source 127.0.0.2
 neighbor 127.0.0.1 timers 3 90
 neighbor 127.0.0.1 timers connect 1
 !
 address-family ipv4 unicast
  neighbor 127.0.0.1 addpath-tx-all-paths
  neighbor 127.0.0.1 default-originate
  neighbor 127.0.0.1 route-map RM_IN in
 exit-address-family
exit
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
```

Send a malformed optional transitive attribute:

```
import socket
import time

OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")

KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")

UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff002b0200000003c0ff00010100eb00ac100b0b001ad908ac100b0b")

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(100)
s.close()
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 6814f2e0138a6ea5e1f83bdd9085d9a77999900b)

11 months agoMerge pull request #15932 from opensourcerouting/8.4-fix-build
David Lamparter [Mon, 6 May 2024 01:01:03 +0000 (03:01 +0200)]
Merge pull request #15932 from opensourcerouting/8.4-fix-build

11 months agobgpd: Use enum bgp_create_error_code as argument in header
Donatas Abraitis [Tue, 13 Jun 2023 13:08:24 +0000 (16:08 +0300)]
bgpd: Use enum bgp_create_error_code as argument in header

```
bgpd/bgp_vty.c:865:5: warning: conflicting types for ‘bgp_vty_return’ due to enum/integer mismatch; have ‘int(struct vty *, enum bgp_create_error_code)’ [-Wenum-int-mismatch]
  865 | int bgp_vty_return(struct vty *vty, enum bgp_create_error_code ret)
      |     ^~~~~~~~~~~~~~
In file included from ./bgpd/bgp_mplsvpn.h:15,
                 from bgpd/bgp_vty.c:48:
./bgpd/bgp_vty.h:148:12: note: previous declaration of ‘bgp_vty_return’ with type ‘int(struct vty *, int)’
  148 | extern int bgp_vty_return(struct vty *vty, int ret);
      |            ^~~~~~~~~~~~~~
```

Fixing stuff regarding GCC13.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit cc280c74cea8183b31f60ef16bda617eca364c9d)

11 months agoospf6d: fix uninitialized warnings
David Lamparter [Sat, 16 Sep 2023 12:17:24 +0000 (14:17 +0200)]
ospf6d: fix uninitialized warnings

GCC 13.2.0 complains:

```
ospf6d/ospf6_intra.c:139:25: error: ‘json_arr’ may be used uninitialized [-Werror=maybe-uninitialized]
ospf6d/ospf6_intra.c:485:20: error: ‘json_arr’ may be used uninitialized [-Werror=maybe-uninitialized]
```

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 55bbef1356418168833fba98d3e7d4691f8f1408)

11 months agolib: replace deprecated ares_gethostbyname
Andrew Cooks [Thu, 25 Apr 2024 07:18:39 +0000 (17:18 +1000)]
lib: replace deprecated ares_gethostbyname

c-ares has deprecated ares_gethostbyname() in version 1.28.0
Replace it with ares_getaddrinfo().

This fixes a build error on Fedora 40.

Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 89a2e4d8257a91d115fa29e02261c33312da5cba)
[equi: thread/event rename conflict fixed]

11 months agolib: replace deprecated ares_process()
Andrew Cooks [Wed, 24 Apr 2024 05:01:28 +0000 (15:01 +1000)]
lib: replace deprecated ares_process()

ares_process(...) has been deprecated.
Replace it with ares_process_fd(...)

Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 4540fa0a3e702f577d378b3fa1f5f26591a0a5ad)

11 months agoMerge pull request #15929 from FRRouting/mergify/bp/stable/8.4/pr-14645
David Lamparter [Sun, 5 May 2024 17:11:51 +0000 (19:11 +0200)]
Merge pull request #15929 from FRRouting/mergify/bp/stable/8.4/pr-14645

11 months agoMerge pull request #15931 from FRRouting/mergify/bp/stable/8.4/pr-14260
David Lamparter [Sun, 5 May 2024 17:11:29 +0000 (19:11 +0200)]
Merge pull request #15931 from FRRouting/mergify/bp/stable/8.4/pr-14260

11 months agoMerge pull request #15928 from FRRouting/mergify/bp/stable/8.4/pr-14245
David Lamparter [Sun, 5 May 2024 17:10:47 +0000 (19:10 +0200)]
Merge pull request #15928 from FRRouting/mergify/bp/stable/8.4/pr-14245

11 months agoMerge pull request #15926 from FRRouting/mergify/bp/stable/8.4/pr-12951
David Lamparter [Sun, 5 May 2024 17:10:04 +0000 (19:10 +0200)]
Merge pull request #15926 from FRRouting/mergify/bp/stable/8.4/pr-12951

Fix use beyond end of stream of labeled unicast parsing (backport #12951)

11 months agoMerge pull request #15925 from FRRouting/mergify/bp/stable/8.4/pr-12950
David Lamparter [Sun, 5 May 2024 17:09:39 +0000 (19:09 +0200)]
Merge pull request #15925 from FRRouting/mergify/bp/stable/8.4/pr-12950

fix #11808 to avoid infinite loops (backport #12950)

11 months agobgpd: Do not process NLRIs if the attribute length is zero
Donatas Abraitis [Tue, 22 Aug 2023 19:52:04 +0000 (22:52 +0300)]
bgpd: Do not process NLRIs if the attribute length is zero

```
3  0x00007f423aa42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
4  0x00007f423aef9740 in core_handler (signo=11, siginfo=0x7fffc414deb0, context=<optimized out>) at lib/sigevent.c:246
5  <signal handler called>
6  0x0000564dea2fc71e in route_set_aspath_prepend (rule=0x564debd66d50, prefix=0x7fffc414ea30, object=0x7fffc414e400)
    at bgpd/bgp_routemap.c:2258
7  0x00007f423aeec7e0 in route_map_apply_ext (map=<optimized out>, prefix=prefix@entry=0x7fffc414ea30,
    match_object=match_object@entry=0x7fffc414e400, set_object=set_object@entry=0x7fffc414e400, pref=pref@entry=0x0) at lib/routemap.c:2690
8  0x0000564dea2d277e in bgp_input_modifier (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, attr=attr@entry=0x7fffc414e770,
    afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_UNICAST, rmap_name=rmap_name@entry=0x0, label=0x0, num_labels=0, dest=0x564debdd5130)
    at bgpd/bgp_route.c:1772
9  0x0000564dea2df762 in bgp_update (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, addpath_id=addpath_id@entry=0,
    attr=0x7fffc414eb50, afi=afi@entry=AFI_IP, safi=<optimized out>, safi@entry=SAFI_UNICAST, type=9, sub_type=0, prd=0x0, label=0x0,
    num_labels=0, soft_reconfig=0, evpn=0x0) at bgpd/bgp_route.c:4374
10 0x0000564dea2e2047 in bgp_nlri_parse_ip (peer=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50, packet=0x7fffc414eaf0)
    at bgpd/bgp_route.c:6249
11 0x0000564dea2c5a58 in bgp_nlri_parse (peer=peer@entry=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50,
    packet=packet@entry=0x7fffc414eaf0, mp_withdraw=mp_withdraw@entry=false) at bgpd/bgp_packet.c:339
12 0x0000564dea2c5d66 in bgp_update_receive (peer=peer@entry=0x7f4238f59010, size=size@entry=109) at bgpd/bgp_packet.c:2024
13 0x0000564dea2c901d in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:2933
14 0x00007f423af0bf71 in event_call (thread=thread@entry=0x7fffc414ee40) at lib/event.c:1995
15 0x00007f423aebb198 in frr_run (master=0x564deb73c670) at lib/libfrr.c:1213
16 0x0000564dea261b83 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:505
```

With the configuration:

```
frr version 9.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-13-140
log file /tmp/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp keepalives
debug bgp neighbor-events
debug bgp updates in
debug bgp updates out
!
router bgp 100
 bgp router-id 9.9.9.9
 no bgp ebgp-requires-policy
 bgp bestpath aigp
 neighbor 172.31.2.47 remote-as 200
 !
 address-family ipv4 unicast
  neighbor 172.31.2.47 default-originate
  neighbor 172.31.2.47 route-map RM_IN in
 exit-address-family
exit
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
!
```

The issue is that we try to process NLRIs even if the attribute length is 0.

Later bgp_update() will handle route-maps and a crash occurs because all the
attributes are NULL, including aspath, where we dereference.

According to the RFC 4271:

A value of 0 indicates that neither the Network Layer
         Reachability Information field nor the Path Attribute field is
         present in this UPDATE message.

But with a fuzzed UPDATE message this can be faked. I think it's reasonable
to skip processing NLRIs if both update_len and attribute_len are 0.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 28ccc24d38df1d51ed8a563507e5d6f6171fdd38)

11 months agobgpd: Check mandatory attributes more carefully for UPDATE message
Donatas Abraitis [Mon, 23 Oct 2023 20:34:10 +0000 (23:34 +0300)]
bgpd: Check mandatory attributes more carefully for UPDATE message

If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.

A crash:

```
bgpd[7834]: [TJ23Y-GY0RH] 127.0.0.1 Unknown attribute is received (type 31, length 16)
bgpd[7834]: [PCFFM-WMARW] 127.0.0.1(donatas-pc) rcvd UPDATE wlen 0 attrlen 20 alen 17
BGP[7834]: Received signal 11 at 1698089639 (si_addr 0x0, PC 0x55eefd375b4a); aborting...
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x6d) [0x7f3205ca939d]
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_signal+0xf3) [0x7f3205ca9593]
BGP[7834]: /usr/local/lib/libfrr.so.0(+0xf5181) [0x7f3205cdd181]
BGP[7834]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f3204ff3980]
BGP[7834]: /usr/lib/frr/bgpd(+0x18ab4a) [0x55eefd375b4a]
BGP[7834]: /usr/local/lib/libfrr.so.0(route_map_apply_ext+0x310) [0x7f3205cd1290]
BGP[7834]: /usr/lib/frr/bgpd(+0x163610) [0x55eefd34e610]
BGP[7834]: /usr/lib/frr/bgpd(bgp_update+0x9a5) [0x55eefd35c1d5]
BGP[7834]: /usr/lib/frr/bgpd(bgp_nlri_parse_ip+0xb7) [0x55eefd35e867]
BGP[7834]: /usr/lib/frr/bgpd(+0x1555e6) [0x55eefd3405e6]
BGP[7834]: /usr/lib/frr/bgpd(bgp_process_packet+0x747) [0x55eefd345597]
BGP[7834]: /usr/local/lib/libfrr.so.0(event_call+0x83) [0x7f3205cef4a3]
BGP[7834]: /usr/local/lib/libfrr.so.0(frr_run+0xc0) [0x7f3205ca10a0]
BGP[7834]: /usr/lib/frr/bgpd(main+0x409) [0x55eefd2dc979]
```

Sending:

```
import socket
import time

OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")

KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")

UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff003c0200000014ff1f001000040146464646460004464646464646664646f50d05800100010200ffff000000")

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(1000)
s.close()
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d8482bf011cb2b173e85b65b4bf3d5061250cdb9)

11 months agobgpd: Handle MP_REACH_NLRI malformed packets with session reset
Donatas Abraitis [Fri, 20 Oct 2023 14:49:18 +0000 (17:49 +0300)]
bgpd: Handle MP_REACH_NLRI malformed packets with session reset

Avoid crashing bgpd.

```
(gdb)
bgp_mp_reach_parse (args=<optimized out>, mp_update=0x7fffffffe140) at bgpd/bgp_attr.c:2341
2341 stream_get(&attr->mp_nexthop_global, s, IPV6_MAX_BYTELEN);
(gdb)
stream_get (dst=0x7fffffffe1ac, s=0x7ffff0006e80, size=16) at lib/stream.c:320
320 {
(gdb)
321 STREAM_VERIFY_SANE(s);
(gdb)
323 if (STREAM_READABLE(s) < size) {
(gdb)
34   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb)

Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
    object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```

With the configuration:

```
 neighbor 127.0.0.1 remote-as external
 neighbor 127.0.0.1 passive
 neighbor 127.0.0.1 ebgp-multihop
 neighbor 127.0.0.1 disable-connected-check
 neighbor 127.0.0.1 update-source 127.0.0.2
 neighbor 127.0.0.1 timers 3 90
 neighbor 127.0.0.1 timers connect 1
 address-family ipv4 unicast
  redistribute connected
  neighbor 127.0.0.1 default-originate
  neighbor 127.0.0.1 route-map RM_IN in
 exit-address-family
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b08afc81c60607a4f736f418f2e3eb06087f1a35)

11 months agobgpd: Don't read the first byte of ORF header if we are ahead of stream
Donatas Abraitis [Sun, 20 Aug 2023 19:15:27 +0000 (22:15 +0300)]
bgpd: Don't read the first byte of ORF header if we are ahead of stream

Reported-by: Iggy Frankovic iggyfran@amazon.com
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 9b855a692e68e0d16467e190b466b4ecb6853702)

11 months agobgpd: Fix use beyond end of stream of labeled unicast parsing
Donald Sharp [Sat, 4 Mar 2023 02:58:33 +0000 (21:58 -0500)]
bgpd: Fix use beyond end of stream of labeled unicast parsing

Fixes a couple crashes associated with attempting to read
beyond the end of the stream.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7404a914b0cafe046703c8381903a80d3def8f8b)

11 months agobabeld: fix #11808 to avoid infinite loops
harryreps [Fri, 3 Mar 2023 23:17:14 +0000 (23:17 +0000)]
babeld: fix #11808 to avoid infinite loops

Replacing continue in loops to goto done so that index of packet buffer
increases.

Signed-off-by: harryreps <harryreps@gmail.com>
(cherry picked from commit ae1e0e1fed77716bc06f181ad68c4433fb5523d0)

13 months agoMerge pull request #15573 from opensourcerouting/fix/backport_bgp_filter_fun_8.4
Russ White [Tue, 19 Mar 2024 14:37:15 +0000 (10:37 -0400)]
Merge pull request #15573 from opensourcerouting/fix/backport_bgp_filter_fun_8.4

BGP memory backports

13 months agobgpd: Ensure community data is freed in some cases.
Donald Sharp [Sat, 2 Mar 2024 14:50:38 +0000 (09:50 -0500)]
bgpd: Ensure community data is freed in some cases.

Customer has this valgrind trace:

Direct leak of 2829120 byte(s) in 70728 object(s) allocated from:
  0 in community_new ../bgpd/bgp_community.c:39
  1 in community_uniq_sort ../bgpd/bgp_community.c:170
  2 in route_set_community ../bgpd/bgp_routemap.c:2342
  3 in route_map_apply_ext ../lib/routemap.c:2673
  4 in subgroup_announce_check ../bgpd/bgp_route.c:2367
  5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914
  6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199
  7 in hash_walk ../lib/hash.c:285
  8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061
  9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059
 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221
 11 in bgp_process_wq ../bgpd/bgp_route.c:3221
 12 in work_queue_run ../lib/workqueue.c:282

The above leak detected by valgrind was from a screenshot so I copied it
by hand.  Any mistakes in line numbers are purely from my transcription.
Additionally this is against a slightly modified 8.5.1 version of FRR.
Code inspection of 8.5.1 -vs- latest master shows the same problem
exists.  Code should be able to be followed from there to here.

What is happening:

There is a route-map being applied that modifes the outgoing community
to a peer.  This is saved in the attr copy created in
subgroup_process_announce_selected.  This community pointer is not
interned.  So the community->refcount is still 0.  Normally when
a prefix is announced, the attr and the prefix are placed on a
adjency out structure where the attribute is interned.  This will
cause the community to be saved in the community hash list as well.
In a non-normal operation when the decision to send is aborted after
the route-map application, the attribute is just dropped and the
pointer to the community is just dropped too, leading to situations
where the memory is leaked.  The usage of bgp suppress-fib would
would be a case where the community is caused to be leaked.
Additionally the previous commit where an unsuppress-map is used
to modify the outgoing attribute but since unsuppress-map was
not considered part of outgoing policy the attribute would be dropped as
well.  This pointer drop also extends to any dynamically allocated
memory saved by the attribute pointer that was not interned yet as well.

So let's modify the return case where the decision is made to
not send the prefix to the peer to always just flush the attribute
to ensure memory is not leaked.

Fixes: #15459
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
13 months agobgpd: Include unsuppress-map as a valid outgoing policy
Donald Sharp [Sat, 2 Mar 2024 14:42:30 +0000 (09:42 -0500)]
bgpd: Include unsuppress-map as a valid outgoing policy

If unsuppress-map is setup for outgoing peers, consider that
policy is being applied as for RFC 8212.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
13 months agobgpd: Ensure that the correct aspath is free'd
Donald Sharp [Wed, 13 Mar 2024 14:26:58 +0000 (10:26 -0400)]
bgpd: Ensure that the correct aspath is free'd

Currently in subgroup_default_originate the attr.aspath
is set in bgp_attr_default_set, which hashs the aspath
and creates a refcount for it.  If this is a withdraw
the subgroup_announce_check and bgp_adj_out_set_subgroup
is called which will intern the attribute.  This will
cause the the attr.aspath to be set to a new value
finally at the bottom of the function it intentionally
uninterns the aspath which is not the one that was
created for this function.  This reduces the other
aspath's refcount by 1 and if a clear bgp * is issued
fast enough the aspath for that will be removed
and the system will crash.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
14 months agoMerge pull request #15343 from FRRouting/mergify/bp/stable/8.4/pr-15327
Donald Sharp [Mon, 12 Feb 2024 02:34:29 +0000 (21:34 -0500)]
Merge pull request #15343 from FRRouting/mergify/bp/stable/8.4/pr-15327

pimd: re-evaluated S,G OILs upon RP changes and empty SG upstream oils (backport #15327)

14 months agopimd: re-evaluated S,G OILs upon RP changes and for empty SG upstream oils
Rajesh Varatharaj [Thu, 8 Feb 2024 02:58:39 +0000 (18:58 -0800)]
pimd: re-evaluated S,G OILs upon RP changes and for empty SG upstream oils

Topology:

TOR11 (FHR) --- LEAF-11---SPINE1 (RP)MSDP SPINE-2(RP)MSDP --- LEAF-12 -- TOR12 (LHR)
        |         |                    | |       |
|         -----------------------------------------------------(ECMP)   |
|         |                                 |               |
 -----------------------------------------------------------------------(ECMP)
Issue:
In some triggers, S,G upstream is preserved even with the PP timer expiry, resulting
in S,G with NULL OILS. This could be because we create a dummy S,G upstream and
dummy channel_oif for *,G, where RPF is UNKNOWN. As a result, PIM+VXLAN traffic is never
forwarded downstream to LHR.

Fix:
when the S,G stream is running, Determine if a reevaluation of the outgoing interface
 list (OIL) is required. S,G upstream should then inherit the OIL from *,G.

Testing:
- Evpn pim tests - TestEvpnPimSingleVtepOneMdt.test_02_broadcast_traffic_spt_zero
- pim-smoke

Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 071d43a052e04de52771b2f03461c407f0ced36f)

15 months agoMerge pull request #15232 from donaldsharp/null_argument_warning_8.4
Donald Sharp [Thu, 25 Jan 2024 14:33:54 +0000 (09:33 -0500)]
Merge pull request #15232 from donaldsharp/null_argument_warning_8.4

bgpd: fix NULL argument warning

15 months agobgpd: fix NULL argument warning
David Lamparter [Thu, 16 Mar 2023 10:00:02 +0000 (11:00 +0100)]
bgpd: fix NULL argument warning

gcc 12.2.0 complains `error: ‘%s’ directive argument is null`, even
though all enum values are covered with a string.  Let's just go with a
`???` default.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
15 months agoMerge pull request #15141 from FRRouting/mergify/bp/stable/8.4/pr-14664
Donald Sharp [Tue, 16 Jan 2024 15:41:40 +0000 (10:41 -0500)]
Merge pull request #15141 from FRRouting/mergify/bp/stable/8.4/pr-14664

isisd: staticd: need to link directly against libyang (backport #14664)

15 months agoisisd: staticd: need to link directly against libyang
Christian Hopps [Fri, 27 Oct 2023 02:51:08 +0000 (22:51 -0400)]
isisd: staticd: need to link directly against libyang

Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 81d1d399521bb18f3fdd5353c9d58c4b3988f225)

18 months agoMerge pull request #14587 from FRRouting/mergify/bp/stable/8.4/pr-13340
Donald Sharp [Fri, 13 Oct 2023 15:39:35 +0000 (11:39 -0400)]
Merge pull request #14587 from FRRouting/mergify/bp/stable/8.4/pr-13340

zebra: Fix connected route deletion when multiple entry exists (backport #13340)

18 months agozebra: Fix connected route deletion when multiple entry exists
Xiao Liang [Thu, 20 Apr 2023 03:40:04 +0000 (11:40 +0800)]
zebra: Fix connected route deletion when multiple entry exists

When multiple interfaces have addresses in the same network, deleting
one of them may cause the wrong connected route being deleted.
For example:

    ip link add veth1 type veth peer veth2
    ip link set veth1 up
    ip link set veth2 up
    ip addr add dev veth1 192.168.0.1/24
    ip addr add dev veth2 192.168.0.2/24
    ip addr flush dev veth1

Zebra deletes the route of interface veth2 rather than veth1.

Should match nexthop against ere->re_nhe instead of ere->re->nhe.

Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit a35ba7ba602f87390cc9cbce3f0ceb61977f0949)

19 months agoMerge pull request #14319 from opensourcerouting/fix/backport_530be6a4d089600f1028439...
Jafar Al-Gharaibeh [Thu, 31 Aug 2023 16:58:58 +0000 (11:58 -0500)]
Merge pull request #14319 from opensourcerouting/fix/backport_530be6a4d089600f1028439ddec420ef651b983b_8.4

ospfd: Prevent use after free( and crash of ospf ) when no router ospf

19 months agoospfd: Prevent use after free( and crash of ospf ) when no router ospf
Donald Sharp [Wed, 30 Aug 2023 14:33:29 +0000 (10:33 -0400)]
ospfd: Prevent use after free( and crash of ospf ) when no router ospf

Consider this config:

router ospf
  redistribute kernel

Then you issue:

no router ospf

ospf will crash with a use after free.

The problem is that the event's associated with the
ospf pointer were shut off then the ospf_external_delete
was called which rescheduled the event.  Let's just move
event deletion to the end of the no router ospf.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
20 months agoMerge pull request #14295 from FRRouting/mergify/bp/stable/8.4/pr-14290
Donald Sharp [Wed, 30 Aug 2023 13:21:23 +0000 (09:21 -0400)]
Merge pull request #14295 from FRRouting/mergify/bp/stable/8.4/pr-14290

bgpd: Use treat-as-withdraw for tunnel encapsulation attribute (backport #14290)

20 months agoMerge pull request #14298 from FRRouting/mergify/bp/stable/8.4/pr-14243
Donatas Abraitis [Wed, 30 Aug 2023 08:33:01 +0000 (11:33 +0300)]
Merge pull request #14298 from FRRouting/mergify/bp/stable/8.4/pr-14243

bgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output (backport #14243)

20 months agobgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output
Donatas Abraitis [Sun, 20 Aug 2023 21:01:42 +0000 (00:01 +0300)]
bgpd: Do not explicitly print MAXTTL value for ebgp-multihop vty output

1. Create /etc/frr/frr.conf
```
frr version 7.5
frr defaults traditional
hostname centos8.localdomain
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
line vty
router bgp 4250001000
  neighbor 192.168.122.207 remote-as 65512
  neighbor 192.168.122.207 ebgp-multihop
```

2. Start FRR
`# systemctl start frr
`
3. Show running configuration. Note that FRR explicitly set and shows the default TTL (225)

```
Building configuration...

Current configuration:
!
frr version 7.5
frr defaults traditional
hostname centos8.localdomain
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 4250001000
 neighbor 192.168.122.207 remote-as 65512
 neighbor 192.168.122.207 ebgp-multihop 255
!
line vty
!
end
```
4. Copy initial frr.conf to frr.conf.new (no changes)
`# cp /etc/frr/frr.conf /root/frr.conf.new
`
5. Run frr-reload.sh:

```
$ /usr/lib/frr/frr-reload.py --test  /root/frr.conf.new
2023-08-20 20:15:48,050  INFO: Called via "Namespace(bindir='/usr/bin', confdir='/etc/frr', daemon='', debug=False, filename='/root/frr.conf.new', input=None, log_level='info', overwrite=False, pathspace=None, reload=False, rundir='/var/run/frr', stdout=False, test=True, vty_socket=None)"
2023-08-20 20:15:48,050  INFO: Loading Config object from file /root/frr.conf.new
2023-08-20 20:15:48,124  INFO: Loading Config object from vtysh show running

Lines To Delete
===============
router bgp 4250001000
 no neighbor 192.168.122.207 ebgp-multihop 255

Lines To Add
============
router bgp 4250001000
 neighbor 192.168.122.207 ebgp-multihop
```

Closes https://github.com/FRRouting/frr/issues/14242

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 767aaa3a80489bfc4ff097f932fc347e3db25b89)

20 months agobgpd: Use treat-as-withdraw for tunnel encapsulation attribute
Donatas Abraitis [Thu, 13 Jul 2023 19:32:03 +0000 (22:32 +0300)]
bgpd: Use treat-as-withdraw for tunnel encapsulation attribute

Before this path we used session reset method, which is discouraged by rfc7606.

Handle this as rfc requires.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit bcb6b58d9530173df41d3a3cbc4c600ee0b4b186)

20 months agoMerge pull request #14212 from opensourcerouting/fix/backport_fedf9119a1964abf8e476f2...
Donald Sharp [Wed, 16 Aug 2023 13:25:00 +0000 (09:25 -0400)]
Merge pull request #14212 from opensourcerouting/fix/backport_fedf9119a1964abf8e476f239d81b3f4ce385b1d_8.4

lib: Allow unsetting walltime-warning and cpu-warning

20 months agovtysh: Print uniq lines when parsing `no service ...`
Donatas Abraitis [Fri, 11 Aug 2023 15:21:12 +0000 (18:21 +0300)]
vtysh: Print uniq lines when parsing `no service ...`

Before this patch:

```
no service cputime-warning
no service cputime-warning
no ipv6 forwarding
no service cputime-warning
no service cputime-warning
no service cputime-warning
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
20 months agolib: Allow unsetting walltime-warning and cpu-warning
Donatas Abraitis [Fri, 11 Aug 2023 15:11:03 +0000 (18:11 +0300)]
lib: Allow unsetting walltime-warning and cpu-warning

With a negative form we get:

```
Internal CLI error [walltime_warning_str]
Internal CLI error [cputime_warning_str]
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
20 months agoMerge pull request #14191 from FRRouting/mergify/bp/stable/8.4/pr-14182
Donald Sharp [Sat, 12 Aug 2023 18:02:54 +0000 (14:02 -0400)]
Merge pull request #14191 from FRRouting/mergify/bp/stable/8.4/pr-14182

bgpd: evpn code was not properly unlocking rd_dest (backport #14182)

20 months agobgpd: evpn code was not properly unlocking rd_dest
Donald Sharp [Fri, 11 Aug 2023 13:53:42 +0000 (09:53 -0400)]
bgpd: evpn code was not properly unlocking rd_dest

Found some code where bgp was not unlocking the dest
and rd_dest when walking the tree attempting to
find something to install.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 1e8ac95bfb757b85d02514dd0f708974cdc22899)

20 months agoMerge pull request #14185 from FRRouting/mergify/bp/stable/8.4/pr-12524
Jafar Al-Gharaibeh [Sat, 12 Aug 2023 00:48:37 +0000 (19:48 -0500)]
Merge pull request #14185 from FRRouting/mergify/bp/stable/8.4/pr-12524

lib, zebra: Fix EVPN nexthop config order (backport #12524)

20 months agolib, zebra: Fix EVPN nexthop config order
Xiao Liang [Thu, 15 Dec 2022 09:04:32 +0000 (17:04 +0800)]
lib, zebra: Fix EVPN nexthop config order

Delay EVPN route addition to synchronize with rib_delete(), which now
uses early route queue.

Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit cea3f7f25a23e485d4f814b670c11c92249568e1)

20 months agoMerge pull request #14134 from FRRouting/mergify/bp/stable/8.4/pr-14129
Donatas Abraitis [Thu, 3 Aug 2023 19:36:29 +0000 (22:36 +0300)]
Merge pull request #14134 from FRRouting/mergify/bp/stable/8.4/pr-14129

bgpd: Fix for session reset issue caused by malformed core attributes  in update message (backport #14129)

20 months agobgpd: Fix session reset issue caused by malformed core attributes
Samanvitha B Bhargav [Wed, 2 Aug 2023 06:10:35 +0000 (23:10 -0700)]
bgpd: Fix session reset issue caused by malformed core attributes

RCA:
On encountering any attribute error for core attributes in update message,
the error handling is set to 'treat as withdraw' and
further parsing of the remaining attributes is skipped.
But the stream pointer is not being correctly adjusted to
point to the next NLRI field skipping the rest of the attributes.
This leads to incorrect parsing of the NLRI field,
which causes BGP session to reset.

Fix:
The stream pointer offset is rightly adjusted to point to the NLRI field correctly
when the malformed attribute is encountered and remaining attribute parsing is skipped.

Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
(cherry picked from commit 70ff940fd1cbf920958116c558150ca5d3200eb8)

21 months agoMerge pull request #13957 from opensourcerouting/fix/route_map_cli_8.4
Donald Sharp [Tue, 11 Jul 2023 15:27:31 +0000 (11:27 -0400)]
Merge pull request #13957 from opensourcerouting/fix/route_map_cli_8.4

lib: make cmd_element->attr a bitmask & clarify

21 months agolib: make cmd_element->attr a bitmask & clarify
David Lamparter [Tue, 4 Oct 2022 11:30:04 +0000 (13:30 +0200)]
lib: make cmd_element->attr a bitmask & clarify

It already "looks" like a bitmask, but we currently can't flag a command
both YANG and HIDDEN at the same time.  It really should be a bitmask.

Also clarify DEPRECATED behaviour (or the absence thereof.)

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
21 months agoMerge pull request #13914 from opensourcerouting/fix/ospf6d_backports_8.4
Donald Sharp [Mon, 3 Jul 2023 12:34:34 +0000 (08:34 -0400)]
Merge pull request #13914 from opensourcerouting/fix/ospf6d_backports_8.4

ospf6d: Crash backports

21 months agoMerge pull request #13906 from FRRouting/mergify/bp/stable/8.4/pr-13895
Donatas Abraitis [Mon, 3 Jul 2023 07:49:58 +0000 (10:49 +0300)]
Merge pull request #13906 from FRRouting/mergify/bp/stable/8.4/pr-13895

ospfd: check for NULLs in ldp-igp sync json code (backport #13895)

21 months agoospf6d: Fix crash because neighbor structure was freed
Donald Sharp [Sat, 1 Jul 2023 15:18:06 +0000 (11:18 -0400)]
ospf6d: Fix crash because neighbor structure was freed

The loading_done event needs a event pointer to prevent
use after free's.  Testing found this:

    ERROR: AddressSanitizer: heap-use-after-free on address 0x613000035130 at pc 0x55ad42d54e5f bp 0x7ffff1e942a0 sp 0x7ffff1e94290
    READ of size 1 at 0x613000035130 thread T0
        #0 0x55ad42d54e5e in loading_done ospf6d/ospf6_neighbor.c:447
        #1 0x55ad42ed7be4 in event_call lib/event.c:1995
        #2 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #3 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #4 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #5 0x55ad42cf2b19 in _start (/usr/lib/frr/ospf6d+0x248b19)

    0x613000035130 is located 48 bytes inside of 384-byte region [0x613000035100,0x613000035280)
    freed by thread T0 here:
        #0 0x7f57998d77a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
        #1 0x55ad42e3b4b6 in qfree lib/memory.c:130
        #2 0x55ad42d5d049 in ospf6_neighbor_delete ospf6d/ospf6_neighbor.c:180
        #3 0x55ad42d1e1ea in interface_down ospf6d/ospf6_interface.c:930
        #4 0x55ad42ed7be4 in event_call lib/event.c:1995
        #5 0x55ad42ed84fe in _event_execute lib/event.c:2086
        #6 0x55ad42d26d7b in ospf6_interface_clear ospf6d/ospf6_interface.c:2847
        #7 0x55ad42d73f16 in ospf6_process_reset ospf6d/ospf6_top.c:755
        #8 0x55ad42d7e98c in clear_router_ospf6_magic ospf6d/ospf6_top.c:778
        #9 0x55ad42d7e98c in clear_router_ospf6 ospf6d/ospf6_top_clippy.c:42
        #10 0x55ad42dc2665 in cmd_execute_command_real lib/command.c:994
        #11 0x55ad42dc2b32 in cmd_execute_command lib/command.c:1053
        #12 0x55ad42dc2fa9 in cmd_execute lib/command.c:1221
        #13 0x55ad42ee3cd6 in vty_command lib/vty.c:591
        #14 0x55ad42ee4170 in vty_execute lib/vty.c:1354
        #15 0x55ad42eec94f in vtysh_read lib/vty.c:2362
        #16 0x55ad42ed7be4 in event_call lib/event.c:1995
        #17 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #18 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #19 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

    previously allocated by thread T0 here:
        #0 0x7f57998d7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
        #1 0x55ad42e3ab22 in qcalloc lib/memory.c:105
        #2 0x55ad42d5c8ff in ospf6_neighbor_create ospf6d/ospf6_neighbor.c:119
        #3 0x55ad42d4c86a in ospf6_hello_recv ospf6d/ospf6_message.c:464
        #4 0x55ad42d4c86a in ospf6_read_helper ospf6d/ospf6_message.c:1884
        #5 0x55ad42d4c86a in ospf6_receive ospf6d/ospf6_message.c:1925
        #6 0x55ad42ed7be4 in event_call lib/event.c:1995
        #7 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
        #8 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
        #9 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Add an actual event pointer and just track it appropriately.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
21 months agoospf6d: Stop crash in ospf6_write
Donald Sharp [Fri, 30 Jun 2023 19:21:43 +0000 (15:21 -0400)]
ospf6d: Stop crash in ospf6_write

I'm seeing crashes in ospf6_write on the `assert(node)`.  The only
sequence of events that I see that could possibly cause this to happen
is this:

a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>

When event_execute is called for ospf6_write, just cancel the t_write
event.  If ospf6_write has more data to send at the end of the function
it will reschedule itself.  I've only seen this crash one time and am
unable to reliably reproduce this at all.  But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
21 months agoospfd: check for NULLs in vty code
Mark Stapp [Fri, 30 Jun 2023 13:44:00 +0000 (09:44 -0400)]
ospfd: check for NULLs in vty code

There were a couple of cli paths that NULL-checked in the
vtysh output path, but not in the json path.

Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit 864a3bc1855ec8027fec8d6f400adb44e1ecbfcf)

22 months agoMerge pull request #13820 from FRRouting/mergify/bp/stable/8.4/pr-13800
Mark Stapp [Tue, 20 Jun 2023 18:22:54 +0000 (14:22 -0400)]
Merge pull request #13820 from FRRouting/mergify/bp/stable/8.4/pr-13800

fix crashes in rip and ripng (backport #13800)

22 months agoRevert "ripngd: Cleanup memory allocations on shutdown"
Igor Ryzhov [Thu, 15 Jun 2023 14:42:05 +0000 (17:42 +0300)]
Revert "ripngd: Cleanup memory allocations on shutdown"

This reverts commit b1d29673ca16e558aea5d632da181555c83980cf.

This commit introduced a crash. When the VRF is deleted, the RIPNG
instance should not be freed, because the NB infrastructure still stores
the pointer to it. The instance should be deleted only when it's actually
deleted from the configuration.

To reproduce the crash:
```
frr# conf t
frr(config)# vrf vrf1
frr(config-vrf)# exit
frr(config)# router ripng vrf vrf1
frr(config-router)# exit
frr(config)# no vrf vrf1
frr(config)# no router ripng vrf vrf1
vtysh: error reading from ripngd: Resource temporarily unavailable (11)Warning: closing connection to ripngd because of an I/O error!
frr(config)#
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 9f6dade90e5e4686f67ae17b42c2873ec7ca6532)

22 months agoRevert "ripd: Cleanup memory allocations on shutdown"
Igor Ryzhov [Thu, 15 Jun 2023 14:35:30 +0000 (17:35 +0300)]
Revert "ripd: Cleanup memory allocations on shutdown"

This reverts commit 3d1588d8ed537e3dbf120e1b2a5ad5b3c00c7897.

This commit introduced a crash. When the VRF is deleted, the RIP instance
should not be freed, because the NB infrastructure still stores the
pointer to it. The instance should be deleted only when it's actually
deleted from the configuration.

To reproduce the crash:
```
frr# conf t
frr(config)# vrf vrf1
frr(config-vrf)# exit
frr(config)# router rip vrf vrf1
frr(config-router)# exit
frr(config)# no vrf vrf1
frr(config)# no router rip vrf vrf1
vtysh: error reading from ripd: Resource temporarily unavailable (11)Warning: closing connection to ripd because of an I/O error!
frr(config)#
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 054ca9b9ee760e23ac5d9f8d26d50e8fca78a887)

22 months agoFRR Release 8.4.4 frr-8.4.4
Jafar Al-Gharaibeh [Fri, 16 Jun 2023 04:31:44 +0000 (23:31 -0500)]
FRR Release 8.4.4

    This a convenience release/tag for house keeping. We currently don't plan to publish
    binary packages with this release.

    Changelog:

bfdd
    Fix malformed session with vrf
    Remove redundant nb destroy callbacks

bgpd
    Aggregate-address memory leak fix
    Bmp fix peer-up ports byte order
    Check 7 bytes for long-lived graceful-restart capability
    Conform bgp_packet.h with coding standards
    Copy the password from the previous peer on peer_xfer_config()
    Do not allow a `no router bgp xxx` when autoimport is happening
    Do not allow l3vni changes when shutting down
    Do not announce routes immediatelly on filter updates
    Ensure stream received has enough data
    Fix bgpd core when unintern attr
    Fix crash for `show bgp ... neighbor received-routes detail|prefix`
    Fix debug output for route-map names when using a unsuppress-map
    Fix ecommunity parsing for as4
    Fix for ain->attr corruption during path update
    Fix lcom->str string length to correctly cover aliases
    Increase buffer size used for dumping bgp to mrt files
    Limit flowspec to no attribute means a implicit withdrawal
    Make bgp_keepalives.c not use mtype_tmp
    Prevent null pointer deref when outputting data
    Treat withdraw variable as a bool
    Use interface name instead of pointer value
    Use the actual pointer type instead of a void

lib
    Adjust only `any` flag for prefix-list entries if destroying
    Destroy `any` flag when creating a prefix-list entry with prefix
    Fix link state memory leak
    Fix vtysh core when handling questionmark
    On bfd peer shutdown actually stop event

ospf6d
    Stop using mtype_tmp in some cases

ospfd, ospf6d
    Add more logging details

ospfd, ospfclient
    Do not just include .c files in another .c

ospfd
    Cleanup some memory leaks on shutdown in ospf_apiserver.c
    Fix for vitual-link crash in signal handler
    Fix interface param type update
    Fix memory leaks w/ `show ip ospf int x json` commands
    Fix ospf_lsa memory leak
    Fix ospf_ti_lfa drop of an entire table
    Fixing summary origination after range configuration
    Free up q_space in early return path
    Log adjacency changes with neighbor ip in addition to neighbor id
    Ospf opaque lsa stale processing fix and topotests.
    Remove mtype_tmp
    Respect loopback's cost that is set and set loopback costs to 0

pbrd
    Fix mismatching in match src-dst

pimd
    Fix use after free issue for ifp's moving vrfs
    Pim not sending register packets after changing from non dr to dr
    Process no-forward bsm packet

ripd
    Fix memory leak for ripd's route-map

tests
    Add test to validate 4-byte ecomm parsing
    Check if prefix-lists with ipv6 any works fine
    Check if route-map works correctly if modifying prefix-lists

tools
    Fix list value remove in frr-reload
    Fix missing remote-as configuration when reload
    Make check flag really work for reload

vtysh
    Give actual pam error messages

zebra
    Cleanup ctx leak on shutdown and turn off event
    Evpn handle del event for dup detected mac
    Fix evpn dup detected local mac del event
    Fix for heap-use-after-free in evpn
    Fix race during shutdown
    Install directly connected route after interface flap
    Reduce creation and fix memory leak of frrscripting pointers
    Unlock the route node when sending route notifications

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
22 months agoMerge pull request #13782 from FRRouting/mergify/bp/stable/8.4/pr-12454
Donald Sharp [Tue, 13 Jun 2023 19:08:00 +0000 (15:08 -0400)]
Merge pull request #13782 from FRRouting/mergify/bp/stable/8.4/pr-12454

bgpd: Ensure stream received has enough data (backport #12454)

22 months agoMerge pull request #13785 from FRRouting/mergify/bp/stable/8.4/pr-13612
Donald Sharp [Tue, 13 Jun 2023 19:06:11 +0000 (15:06 -0400)]
Merge pull request #13785 from FRRouting/mergify/bp/stable/8.4/pr-13612

ospfd: fix interface param type update (backport #13612)

22 months agoospfd: fix interface param type update
Chirag Shah [Fri, 26 May 2023 20:43:50 +0000 (13:43 -0700)]
ospfd: fix interface param type update

interface link update event needs
to be handle properly in ospf interface
cache.

Example:
When vrf (interface) is created its default type
would be set to BROADCAST because ifp->status
is not set to VRF.
Subsequent link event sets ifp->status to vrf,
ospf interface update need to compare current type
to new default type which would be VRF (OSPF_IFTYPE_LOOPBACK).
Since ospf type param was created in first add event,
ifp vrf link event didn't update ospf type param which
leads to treat vrf as non loopback interface.

Ticket:#3459451
Testing Done:

Running config suppose to bypass rendering default
network broadcast for loopback/vrf types.

Before fix:

vrf vrf1
 vni 4001
exit-vrf
!
interface vrf1
 ip ospf network broadcast
exit

After fix: (interface vrf1 is not displayed).

vrf vrf1
 vni 4001
exit-vrf

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 0d005b2d5c294d9d0a8db9d8beca83b97e0fd8ff)

22 months agobgpd: Ensure stream received has enough data
Donald Sharp [Tue, 6 Dec 2022 15:23:11 +0000 (10:23 -0500)]
bgpd: Ensure stream received has enough data

BGP_PREFIX_SID_SRV6_L3_SERVICE attributes must not
fully trust the length value specified in the nlri.
Always ensure that the amount of data we need to read
can be fullfilled.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 06431bfa7570f169637ebb5898f0b0cc3b010802)

22 months agoMerge pull request #13737 from FRRouting/mergify/bp/stable/8.4/pr-13645
Donatas Abraitis [Fri, 9 Jun 2023 06:10:50 +0000 (09:10 +0300)]
Merge pull request #13737 from FRRouting/mergify/bp/stable/8.4/pr-13645

bfdd: remove redundant nb destroy callbacks (backport #13645)

22 months agobfdd: remove redundant nb destroy callbacks
Igor Ryzhov [Wed, 31 May 2023 12:28:08 +0000 (15:28 +0300)]
bfdd: remove redundant nb destroy callbacks

Fixes warning logs:
```
2023/05/29 20:11:50 BFD: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-bfdd:bfdd/bfd/profile/minimum-ttl'
2023/05/29 20:11:50 BFD: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-bfdd:bfdd/bfd/sessions/multi-hop/minimum-ttl'
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit f7884aedf7a1249e3aae71b6a66c9a0f0915c4ef)

22 months agoMerge pull request #13713 from FRRouting/mergify/bp/stable/8.4/pr-13693
Donald Sharp [Wed, 7 Jun 2023 12:07:31 +0000 (08:07 -0400)]
Merge pull request #13713 from FRRouting/mergify/bp/stable/8.4/pr-13693

tools: fix list value remove in frr-reload (backport #13693)

22 months agotools: fix list value remove in frr-reload
Chirag Shah [Tue, 6 Jun 2023 04:48:12 +0000 (21:48 -0700)]
tools: fix list value remove in frr-reload

There might be a time element(s) from
temporary list are removed more than once
which leads to valueError in certain python3
version.

commit-id 1543f58b5 did not handle valueError
properly. This caused regression where
prefix-list config leads to delete followed
by add.

The new fix should just pass the exception as
value removal from list_to_add or list_to_del
is best effort.
This allows prefix-list config has no change
then removes the lines from lines_to_del and
lines_to_add properly.

Ticket:#3490252
Testing:

Configure prefix-list in frr.conf and perform
multiple frr-reload. After first reload operatoin
subsequent ones should not result in delete followed
by add of the prefix-list but rather no-op operation.

(Pdb) lines_to_add
[(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_add_to_del
[(('ip prefix-list FOO permit 10.2.1.0/24',), None),
 (('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) c
> /usr/lib/frr/frr-reload.py(1562)ignore_delete_re_add_lines()
-> return (lines_to_add, lines_to_del)
(Pdb) lines_to_add
[]
(Pdb) lines_to_del
[]

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 9845c09d61a7e509bfae369648cb5f9893455ac4)

22 months agoMerge pull request #13695 from FRRouting/mergify/bp/stable/8.4/pr-13649
Donatas Abraitis [Tue, 6 Jun 2023 08:08:04 +0000 (11:08 +0300)]
Merge pull request #13695 from FRRouting/mergify/bp/stable/8.4/pr-13649

zebra: Unlock the route node when sending route notifications (backport #13649)

22 months agozebra: Unlock the route node when sending route notifications
Donald Sharp [Wed, 31 May 2023 15:40:07 +0000 (11:40 -0400)]
zebra: Unlock the route node when sending route notifications

When using a context to send route notifications to upper
level protocols, the code was using a locking function to
get the route node.  There is no need for this to be locked
as such FRR should free it up.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 82c6e4fea54eb65e153e6bc45bb718367b0b5132)

22 months agoMerge pull request #13663 from FRRouting/mergify/bp/stable/8.4/pr-13637
Donald Sharp [Fri, 2 Jun 2023 00:32:52 +0000 (20:32 -0400)]
Merge pull request #13663 from FRRouting/mergify/bp/stable/8.4/pr-13637

lib: fix vtysh core when handling questionmark (backport #13637)

22 months agolib: fix vtysh core when handling questionmark
Yuan Yuan [Tue, 30 May 2023 19:20:09 +0000 (19:20 +0000)]
lib: fix vtysh core when handling questionmark

When issue vtysh command with ?, the initial buf size for the
element is 16. Then it would loop through each element in the cmd
output vector. If the required size for printing out the next
element is larger than the current buf size, realloc the buf memory
by doubling the current buf size regardless of the actual size
that's needed. This would cause vtysh core when the doubled size
is not enough for the next element.

Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
(cherry picked from commit f8aa257997a6a6f69ec5d5715ab04d7cbfae1d1c)

23 months agoMerge pull request #13643 from FRRouting/mergify/bp/stable/8.4/pr-13634
Donatas Abraitis [Wed, 31 May 2023 08:10:00 +0000 (11:10 +0300)]
Merge pull request #13643 from FRRouting/mergify/bp/stable/8.4/pr-13634

bgpd: fix bgpd core when unintern attr (backport #13634)

23 months agobgpd: fix bgpd core when unintern attr
Yuan Yuan [Tue, 30 May 2023 18:53:32 +0000 (18:53 +0000)]
bgpd: fix bgpd core when unintern attr

When the remote peer is neither EBGP nor confed, aspath is the
shadow copy of attr->aspath in bgp_packet_attribute(). Striping
AS4_PATH should not be done on the aspath directly, since
that would lead to bgpd core dump when unintern the attr.

Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
(cherry picked from commit 32af4995aae647cf9d7c70347ec37b57279ea807)

23 months agoMerge pull request #13615 from FRRouting/mergify/bp/stable/8.4/pr-13608
Donatas Abraitis [Sat, 27 May 2023 17:05:17 +0000 (20:05 +0300)]
Merge pull request #13615 from FRRouting/mergify/bp/stable/8.4/pr-13608

vtysh: Give actual pam error messages (backport #13608)

23 months agovtysh: Give actual pam error messages
Donald Sharp [Fri, 26 May 2023 11:44:11 +0000 (07:44 -0400)]
vtysh: Give actual pam error messages

Code was was written where the pam error message put out
was the result from a previous call to the pam modules
instead of the current call to the pam module.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 8495b425bd056d405704df9e756560942d6815c1)

23 months agoMerge pull request #13572 from FRRouting/mergify/bp/stable/8.4/pr-13506
Donatas Abraitis [Mon, 22 May 2023 19:05:56 +0000 (22:05 +0300)]
Merge pull request #13572 from FRRouting/mergify/bp/stable/8.4/pr-13506

bfdd: Fix malformed session with vrf (backport #13506)

23 months agobfdd: Fix malformed session with vrf
anlan_cs [Wed, 10 May 2023 14:04:33 +0000 (22:04 +0800)]
bfdd: Fix malformed session with vrf

With this configuration:

```
bfd
 peer 33:33::66 local-address 33:33::88 vrf vrf8 interface enp1s0
 exit
 !
exit
```

The bfd session can't be established with error:

```
bfdd[18663]: [YA0Q5-C0BPV] control-packet: wrong vrfid. [mhop:no peer:33:33::66 local:33:33::88 port:2 vrf:61]
```

The vrf check should use the carefully adjusted `vrfid`, which is
based on globally/reliable interface.  We can't believe the
`bvrf->vrf->vrf_id` because the `/proc/sys/net/ipv4/udp_l3mdev_accept`
maybe is set "1" in VRF-lite backend even with security drawback.

Just correct the vrf check.

Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit b17c179664da7331a4669a1cf548e4e9c48a5477)

23 months agoMerge pull request #13503 from FRRouting/mergify/bp/stable/8.4/pr-13489
Jafar Al-Gharaibeh [Thu, 11 May 2023 04:00:27 +0000 (23:00 -0500)]
Merge pull request #13503 from FRRouting/mergify/bp/stable/8.4/pr-13489

ospfd: OSPF opaque LSA stale processing fix and topotests. (backport #13489)

23 months ago ospfd: OSPF opaque LSA stale processing fix and topotests.
Acee [Tue, 9 May 2023 20:51:03 +0000 (16:51 -0400)]
    ospfd: OSPF opaque LSA stale processing fix and topotests.

        1. Fix OSPF opaque LSA processing to preserve the stale opaque
            LSAs in the Link State Database for 60 seconds consistent with
            what is done for other LSA types.
         2. Add a topotest that tests for cases where ospfd is restarted
            and a stale OSPF opaque LSA exists in the OSPF routing domain
            both when the LSA is purged and when the LSA is reoriginagted
            with a more recent instance.

Signed-off-by: Acee <aceelindem@gmail.com>
(cherry picked from commit 4e7eb1e62ce54ebcf78622682de962fdeff20b80)

23 months agoMerge pull request #13501 from FRRouting/mergify/bp/stable/8.4/pr-13485
Donald Sharp [Wed, 10 May 2023 18:23:47 +0000 (14:23 -0400)]
Merge pull request #13501 from FRRouting/mergify/bp/stable/8.4/pr-13485

ospfd: Respect loopback's cost that is set and set loopback costs to 0 (backport #13485)

23 months agoospfd: Respect loopback's cost that is set and set loopback costs to 0
Donald Sharp [Tue, 9 May 2023 17:10:35 +0000 (13:10 -0400)]
ospfd: Respect loopback's cost that is set and set loopback costs to 0

When setting an loopback's cost, set the value to 0, unless the operator
has assigned a value for the loopback's cost.

RFC states:

If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network. The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.

FRR is going to allow this to be overridden if the operator specifically
sets a value too.

Fixes: #13472
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit dd2bc4fb406cc9284d35ef623ebb8838cb158bc8)

23 months agoMerge pull request #13482 from FRRouting/mergify/bp/stable/8.4/pr-13445
Donald Sharp [Tue, 9 May 2023 17:31:10 +0000 (13:31 -0400)]
Merge pull request #13482 from FRRouting/mergify/bp/stable/8.4/pr-13445

zebra: Reduce creation and fix memory leak of frrscripting pointers (backport #13445)

23 months agozebra: Reduce creation and fix memory leak of frrscripting pointers
Donald Sharp [Fri, 5 May 2023 15:05:12 +0000 (11:05 -0400)]
zebra: Reduce creation and fix memory leak of frrscripting pointers

There are two issues being addressed:

a) The ZEBRA_ON_RIB_PROCESS_HOOK_CALL script point
was creating a fs pointer per dplane ctx in
rib_process_dplane_results().

b) The fs pointer was not being deleted and directly
leaked.

For (a) Move the creation of the fs to outside
the do while loop.

For (b) At function end ensure that the pointer
is actually deleted.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit d8be1399720ca36485b6a2209b143679b01b83cb)

23 months agoMerge pull request #13443 from FRRouting/mergify/bp/stable/8.4/pr-13436
Donatas Abraitis [Fri, 5 May 2023 16:49:22 +0000 (19:49 +0300)]
Merge pull request #13443 from FRRouting/mergify/bp/stable/8.4/pr-13436

ospfd: Fix memory leaks w/ `show ip ospf int X json` commands (backport #13436)

23 months agoospfd: Fix memory leaks w/ `show ip ospf int X json` commands
Donald Sharp [Thu, 4 May 2023 16:53:42 +0000 (12:53 -0400)]
ospfd: Fix memory leaks w/ `show ip ospf int X json` commands

FRR has a memory leak in the case when int X does not
exist and a memory leak when int X does exist.  Fix
these

Fixes: #13434
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 74e21732db129f7287d5ab227e45f305c5dbf34e)

23 months agoMerge pull request #13419 from FRRouting/mergify/bp/stable/8.4/pr-13020
Jafar Al-Gharaibeh [Thu, 4 May 2023 14:00:46 +0000 (09:00 -0500)]
Merge pull request #13419 from FRRouting/mergify/bp/stable/8.4/pr-13020

pimd: PIM not sending register packets after changing from non DR to DR (backport #13020)

23 months agopimd: PIM not sending register packets after changing from non DR to DR
Sai Gomathi N [Fri, 17 Mar 2023 10:51:16 +0000 (03:51 -0700)]
pimd: PIM not sending register packets after changing from non DR to DR

When the router is non dr for an interface, it installs mroute to drop
the packets from directly connected source. This was done to avoid packets
coming to cpu as nocache hit. Later when it gets change from non-DR to DR,
these entries are not cleared. So the packets are still dropped.
This causes register packets not getting generated.
So cleaning up the mroute entries and channel oil without
upstream reference which was created to drop.

Co-authored-by: Saravanan K <saravanank@vmware.com>
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
(cherry picked from commit 1c883aef96013753f5467ba5e5028dee0f0a82c5)

2 years agoMerge pull request #13372 from FRRouting/mergify/bp/stable/8.4/pr-13330
Donatas Abraitis [Mon, 24 Apr 2023 18:28:33 +0000 (21:28 +0300)]
Merge pull request #13372 from FRRouting/mergify/bp/stable/8.4/pr-13330

zebra: EVPN handle duplicate detected local mac delete event (backport #13330)

2 years agozebra:fix evpn dup detected local mac del event
Chirag Shah [Sat, 22 Oct 2022 23:00:14 +0000 (16:00 -0700)]
zebra:fix evpn dup detected local mac del event

The current local mac delete event send to flag with force
always which breaks the duplicate detected MACs where
it requires to be resynced from bgpd to earlier state.

Ticket:#3233019
Issue:3233019

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 89844a967858d34de99bad8dcb410b4ab4e1dece)

2 years agozebra: evpn handle del event for dup detected mac
Chirag Shah [Wed, 1 Dec 2021 04:42:01 +0000 (20:42 -0800)]
zebra: evpn handle del event for dup detected mac

Upon receiving local mobility event for MAC + NEIGH,
both are detected as duplicate upon hitting DAD threshold.

Duplicated detected ( freezed) MAC + NEIGH are not known
to bgpd.

If locally learnt MAC + NEIGH are deleted in kernel,
the MAC is marked as AUTO after sending delete event
to bgpd.

Bgpd only reinstalls best route for MAC_IP route (NEIGH)
but not for MAC event.
This puts a situation where MAC is AUTO state and
associated neigh as remote.

Fix:
DUPLICATE + LOCAL MAC deletion, set MAC delete request
as reinstall from bgpd.

Ticket:#2873307
Reviewed By:
Testing Done:

Freeze MAC + two NEIGHs in local mobility event.
Delete MAC and NEIGH from kerenl.
bgp rsync remote mac route which puts MAC to remote state.

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit ad7685de2871996469d370192af7afafc234a3ca)

2 years agoMerge pull request #13343 from FRRouting/mergify/bp/stable/8.4/pr-13341
Donald Sharp [Fri, 21 Apr 2023 11:10:23 +0000 (07:10 -0400)]
Merge pull request #13343 from FRRouting/mergify/bp/stable/8.4/pr-13341

bgpd: Fix lcom->str string length to correctly cover aliases (backport #13341)

2 years agobgpd: Fix lcom->str string length to correctly cover aliases
Donald Sharp [Thu, 20 Apr 2023 20:27:20 +0000 (16:27 -0400)]
bgpd: Fix lcom->str string length to correctly cover aliases

If you have a very large number of large communities whose
string length happened to be greater than BUFSIZ FRR's bgpd
would crash.  This is because bgpd would write beyond
the end of the string.

Originally the code auto-calculated the string size appropriately
but commit ed0e57e3f079352714c3a3a8a5b0dddf4aadfe1d modified
the string length to be a hard coded BUFSIZ.  When a route-map
like this is added:

route-map LARGE-OUT permit 10
 set large-community 4635:0:0 4635:1:906 4635:1:2906 4635:1:4515 4635:1:4594 4635:1:4641 4635:1:4760 4635:1:7979 4635:1:9253 4635:1:9293 4635:1:9304 4635:1:9908 4635:1:13335 4635:1:16265 4635:1:17924 4635:1:18013 4635:1:20940 4635:1:22822 4635:1:24429 4635:1:24482 4635:1:32590 4635:1:32934 4635:1:36692 4635:1:38008 4635:1:38819 4635:1:41378 4635:1:45753 4635:1:46489 4635:1:49544 4635:1:51847 4635:1:54574 4635:1:54994 4635:1:55720 4635:1:56059 4635:1:57724 4635:1:65021 4635:1:134823 4635:1:136907 4635:1:146961 24115:0:24115 24115:1:906 24115:1:2906 24115:1:4515 24115:1:4594 24115:1:4641 24115:1:4760 24115:1:7979 24115:1:9253 24115:1:9293 24115:1:9304 24115:1:9908 24115:1:13335 24115:1:16265 24115:1:17924 24115:1:18013 24115:1:20940 24115:1:22822 24115:1:24429 24115:1:24482 24115:1:32590 24115:1:32934 24115:1:36692 24115:1:38008 24115:1:38819 24115:1:41378 24115:1:45753 24115:1:46489 24115:1:49544 24115:1:51847 24115:1:54574 24115:1:54994 24115:1:55720 24115:1:56059 24115:1:57724 24115:1:65021 24115:1:134823 24115:1:136907 24115:1:100000 24115:1:100001 24115:1:100002
exit

BGP would have issues and crash.

Modify the code to correctly determine the string length of the communities
and to also double check if the string has an alias and ensure that the
string is still sufficiently large enough.  If not auto size it again.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 8cb4892c0669d916557d693b878420faec8e6e2a)