| 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 |