Debian Patches

Status for frr/7.5.1-1.1+deb11u2

Patch Description Author Forwarded Bugs Origin Last update
0001-yang-fix-zebra-module.patch yang: fix zebra module Igor Ryzhov <iryzhov@nfware.com> no 2021-04-22
0001-bgpd-Implement-rfc9072.patch [PATCH] bgpd: Implement rfc9072 Donatas Abraitis <donatas.abraitis@gmail.com> no 2021-11-20
CVE-2022-37032.patch [PATCH] bgpd: Make sure hdr length is at a minimum of what is expected

Ensure that if the capability length specified is enough data.		 Donald Sharp <sharpd@nvidia.com> no 2022-07-21
CVE-2022-36440_40302.patch [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.		 Donald Sharp <sharpd@nvidia.com> no 2022-09-30
CVE-2022-40318.patch [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.		 Donald Sharp <sharpd@nvidia.com> no 2022-09-30
CVE-2022-43681.patch [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.

(cherry picked from commit 766eec1b7accffe2c04a5c9ebb14e9f487bb9f78)		 Donald Sharp <sharpd@nvidia.com> no 2022-11-02
CVE-2023-31490.patch [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.		 Donald Sharp <sharpd@nvidia.com> no 2022-12-06
CVE-2023-38802.patch [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.

(cherry picked from commit bcb6b58d9530173df41d3a3cbc4c600ee0b4b186)		 Donatas Abraitis <donatas@opensourcerouting.org> no 2023-07-13
CVE-2023-41358.patch [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.

(cherry picked from commit 28ccc24d38df1d51ed8a563507e5d6f6171fdd38)		 Donatas Abraitis <donatas@opensourcerouting.org> no 2023-08-22

All known versions for source package 'frr'

Links