yang/frr-zebra.yang | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)

 yang: fix zebra module

Fixes: #8521
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>

bgpd/bgp_open.c | 123 89 + 34 - 0 !
bgpd/bgp_open.h | 15 12 + 3 - 0 !
bgpd/bgp_packet.c | 53 44 + 9 - 0 !
bgpd/bgp_vty.c | 47 47 + 0 - 0 !
bgpd/bgpd.c | 1 1 + 0 - 0 !
bgpd/bgpd.h | 4 4 + 0 - 0 !
6 files changed, 197 insertions(+), 46 deletions(-)

 [patch] bgpd: implement rfc9072

Related: https://datatracker.ietf.org/doc/html/rfc9072

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd/bgp_packet.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 [patch] bgpd: make sure hdr length is at a minimum of what is
 expected

Ensure that if the capability length specified is enough data.

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

bgpd/bgp_open.c | 27 21 + 6 - 0 !
1 file changed, 21 insertions(+), 6 deletions(-)

 [patch] bgpd: ensure frr has enough data to read 2 bytes in
 peek_for_as4_capability

In peek_for_as4_capability the code is checking that the
stream has at least 2 bytes to read ( the opt_type and the
opt_length ).  However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes.  Which is not good
since the packet could be badly formated.  Ensure that
FRR has the appropriate data length to read the data.

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

bgpd/bgp_open.c | 35 28 + 7 - 0 !
1 file changed, 28 insertions(+), 7 deletions(-)

 [patch] bgpd: ensure frr has enough data to read 2 bytes in
 bgp_open_option_parse

In bgp_open_option_parse the code is checking that the
stream has at least 2 bytes to read ( the opt_type and
the opt_length).  However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes.  Which is not good
since the packet could be badly formateed.  Ensure that
FRR has the appropriate data length to read the data.

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

bgpd/bgp_packet.c | 19 19 + 0 - 0 !
1 file changed, 19 insertions(+)

 [patch] bgpd: ensure that bgp open message stream has enough data to
 read

If a operator receives an invalid packet that is of insufficient size
then it is possible for BGP to assert during reading of the packet
instead of gracefully resetting the connection with the peer.

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

bgpd/bgp_attr.c | 76 24 + 52 - 0 !
1 file changed, 24 insertions(+), 52 deletions(-)

 [patch] 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>

bgpd/bgp_attr.c | 61 25 + 36 - 0 !
1 file changed, 25 insertions(+), 36 deletions(-)

 [patch 1/2] 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)

bgpd/bgp_packet.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] 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)