rpms
/
frr
7
0
Fork 0
Code Issues Pull Requests Releases Activity

CVE-2023-38406 CVE-2023-38407 CVE-2023-47234 CVE-2023-47235

This commit is contained in:
Andrew Lukoshko 2024-01-12 13:50:00 +00:00
parent 742d4de4d8
commit 029438c4c6
8 changed files with 480 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

128
SOURCES/0015-CVE-2023-38802.patch Normal file
View File

@ -0,0 +1,128 @@
From bcb6b58d9530173df41d3a3cbc4c600ee0b4b186 Mon Sep 17 00:00:00 2001
From: Donatas Abraitis <donatas@opensourcerouting.org>
Date: Thu, 13 Jul 2023 22:32:03 +0300
Subject: [PATCH] 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>
---
bgpd/bgp_attr.c | 61 ++++++++++++++++++++-----------------------------
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
index dcf0f4d47cfb..8c53191d680f 100644
--- a/bgpd/bgp_attr.c
+++ b/bgpd/bgp_attr.c
@@ -1301,6 +1301,7 @@ bgp_attr_malformed(struct bgp_attr_parser_args *args, uint8_t subcode,
case BGP_ATTR_LARGE_COMMUNITIES:
case BGP_ATTR_ORIGINATOR_ID:
case BGP_ATTR_CLUSTER_LIST:
+ case BGP_ATTR_ENCAP:
return BGP_ATTR_PARSE_WITHDRAW;
case BGP_ATTR_MP_REACH_NLRI:
case BGP_ATTR_MP_UNREACH_NLRI:
@@ -2434,26 +2435,21 @@ bgp_attr_ipv6_ext_communities(struct bgp_attr_parser_args *args)
}
/* Parse Tunnel Encap attribute in an UPDATE */
-static int bgp_attr_encap(uint8_t type, struct peer *peer, /* IN */
- bgp_size_t length, /* IN: attr's length field */
- struct attr *attr, /* IN: caller already allocated */
- uint8_t flag, /* IN: attr's flags field */
- uint8_t *startp)
+static int bgp_attr_encap(struct bgp_attr_parser_args *args)
{
- bgp_size_t total;
uint16_t tunneltype = 0;
-
- total = length + (CHECK_FLAG(flag, BGP_ATTR_FLAG_EXTLEN) ? 4 : 3);
+ struct peer *const peer = args->peer;
+ struct attr *const attr = args->attr;
+ bgp_size_t length = args->length;
+ uint8_t type = args->type;
+ uint8_t flag = args->flags;
if (!CHECK_FLAG(flag, BGP_ATTR_FLAG_TRANS)
|| !CHECK_FLAG(flag, BGP_ATTR_FLAG_OPTIONAL)) {
- zlog_info(
- "Tunnel Encap attribute flag isn't optional and transitive %d",
- flag);
- bgp_notify_send_with_data(peer, BGP_NOTIFY_UPDATE_ERR,
- BGP_NOTIFY_UPDATE_ATTR_FLAG_ERR,
- startp, total);
- return -1;
+ zlog_err("Tunnel Encap attribute flag isn't optional and transitive %d",
+ flag);
+ return bgp_attr_malformed(args, BGP_NOTIFY_UPDATE_OPT_ATTR_ERR,
+ args->total);
}
if (BGP_ATTR_ENCAP == type) {
@@ -2461,12 +2457,11 @@ static int bgp_attr_encap(uint8_t type, struct peer *peer, /* IN */
uint16_t tlv_length;
if (length < 4) {
- zlog_info(
+ zlog_err(
"Tunnel Encap attribute not long enough to contain outer T,L");
- bgp_notify_send_with_data(
- peer, BGP_NOTIFY_UPDATE_ERR,
- BGP_NOTIFY_UPDATE_OPT_ATTR_ERR, startp, total);
- return -1;
+ return bgp_attr_malformed(args,
+ BGP_NOTIFY_UPDATE_OPT_ATTR_ERR,
+ args->total);
}
tunneltype = stream_getw(BGP_INPUT(peer));
tlv_length = stream_getw(BGP_INPUT(peer));
@@ -2496,13 +2491,11 @@ static int bgp_attr_encap(uint8_t type, struct peer *peer, /* IN */
}
if (sublength > length) {
- zlog_info(
- "Tunnel Encap attribute sub-tlv length %d exceeds remaining length %d",
- sublength, length);
- bgp_notify_send_with_data(
- peer, BGP_NOTIFY_UPDATE_ERR,
- BGP_NOTIFY_UPDATE_OPT_ATTR_ERR, startp, total);
- return -1;
+ zlog_err("Tunnel Encap attribute sub-tlv length %d exceeds remaining length %d",
+ sublength, length);
+ return bgp_attr_malformed(args,
+ BGP_NOTIFY_UPDATE_OPT_ATTR_ERR,
+ args->total);
}
/* alloc and copy sub-tlv */
@@ -2550,13 +2543,10 @@ static int bgp_attr_encap(uint8_t type, struct peer *peer, /* IN */
if (length) {
/* spurious leftover data */
- zlog_info(
- "Tunnel Encap attribute length is bad: %d leftover octets",
- length);
- bgp_notify_send_with_data(peer, BGP_NOTIFY_UPDATE_ERR,
- BGP_NOTIFY_UPDATE_OPT_ATTR_ERR,
- startp, total);
- return -1;
+ zlog_err("Tunnel Encap attribute length is bad: %d leftover octets",
+ length);
+ return bgp_attr_malformed(args, BGP_NOTIFY_UPDATE_OPT_ATTR_ERR,
+ args->total);
}
return 0;
@@ -3396,8 +3386,7 @@ enum bgp_attr_parse_ret bgp_attr_parse(struct peer *peer, struct attr *attr,
case BGP_ATTR_VNC:
#endif
case BGP_ATTR_ENCAP:
- ret = bgp_attr_encap(type, peer, length, attr, flag,
- startp);
+ ret = bgp_attr_encap(&attr_args);
break;
case BGP_ATTR_PREFIX_SID:
ret = bgp_attr_prefix_sid(&attr_args);

0
SOURCES/0015-max-ttl-reload.patch → SOURCES/0016-max-ttl-reload.patch
View File

48
SOURCES/0017-fix-crash-in-plist-update.patch Normal file
View File

@ -0,0 +1,48 @@
From 0f9e4c4a36cf2b0dd585a7ef97acccb8eebdf7bd Mon Sep 17 00:00:00 2001
From: Chirag Shah <chirag@nvidia.com>
Date: Mon, 25 Jan 2021 11:44:56 -0800
Subject: [PATCH] lib: fix a crash in plist update
Problem:
Prefix-list with mulitiple rules, an update to
a rule/sequence with different prefix/prefixlen
reset prefix-list next-base pointer to avoid
having stale value.
In some case the old next-bast's reference leads
to an assert in tri (trie_install_fn ) add.
bt:
(object=0x55576a4c8a00, updptr=0x55576a4b97e0) at lib/plist.c:560
(plist=0x55576a4a1770, pentry=0x55576a4c8a00) at lib/plist.c:585
(ple=0x55576a4c8a00) at lib/plist.c:745
(args=0x7fffe04beb50) at lib/filter_nb.c:1181
Solution:
Reset prefix-list next-base pointer whenver a
sequence/rule is updated.
Ticket:CM-33109
Testing Done:
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
(cherry picked from commit f7f101156eb0e225f375f12cf4f863ebbe3fed03)
---
lib/plist.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/plist.c b/lib/plist.c
index 981e86e2a..c746d1946 100644
--- a/lib/plist.c
+++ b/lib/plist.c
@@ -684,6 +684,7 @@ void prefix_list_entry_update_start(struct prefix_list_entry *ple)
if (pl->head || pl->tail || pl->desc)
pl->master->recent = pl;
+ ple->next_best = NULL;
ple->installed = false;
}
--
2.41.0

34
SOURCES/0018-CVE-2023-38406.patch Normal file
View File

@ -0,0 +1,34 @@
From 0b999c886e241c52bd1f7ef0066700e4b618ebb3 Mon Sep 17 00:00:00 2001
From: Donald Sharp <sharpd@nvidia.com>
Date: Thu, 23 Feb 2023 13:29:32 -0500
Subject: [PATCH] bgpd: Flowspec overflow issue
According to the flowspec RFC 8955 a flowspec nlri is <length, <nlri data>>
Specifying 0 as a length makes BGP get all warm on the inside. Which
in this case is not a good thing at all. Prevent warmth, stay cold
on the inside.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
---
bgpd/bgp_flowspec.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/bgpd/bgp_flowspec.c b/bgpd/bgp_flowspec.c
index 8d5ca5e77779..f9debe43cd45 100644
--- a/bgpd/bgp_flowspec.c
+++ b/bgpd/bgp_flowspec.c
@@ -127,6 +127,13 @@ int bgp_nlri_parse_flowspec(struct peer *peer, struct attr *attr,
psize);
return BGP_NLRI_PARSE_ERROR_PACKET_OVERFLOW;
}
+
+ if (psize == 0) {
+ flog_err(EC_BGP_FLOWSPEC_PACKET,
+ "Flowspec NLRI length 0 which makes no sense");
+ return BGP_NLRI_PARSE_ERROR_PACKET_OVERFLOW;
+ }
+
if (bgp_fs_nlri_validate(pnt, psize, afi) < 0) {
flog_err(
EC_BGP_FLOWSPEC_PACKET,

54
SOURCES/0019-CVE-2023-38407.patch Normal file
View File

@ -0,0 +1,54 @@
From 7404a914b0cafe046703c8381903a80d3def8f8b Mon Sep 17 00:00:00 2001
From: Donald Sharp <sharpd@nvidia.com>
Date: Fri, 3 Mar 2023 21:58:33 -0500
Subject: [PATCH] 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>
---
bgpd/bgp_label.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/bgpd/bgp_label.c b/bgpd/bgp_label.c
index 0cad119af101..c4a5277553ba 100644
--- a/bgpd/bgp_label.c
+++ b/bgpd/bgp_label.c
@@ -297,6 +297,9 @@ static int bgp_nlri_get_labels(struct peer *peer, uint8_t *pnt, uint8_t plen,
uint8_t llen = 0;
uint8_t label_depth = 0;
+ if (plen < BGP_LABEL_BYTES)
+ return 0;
+
for (; data < lim; data += BGP_LABEL_BYTES) {
memcpy(label, data, BGP_LABEL_BYTES);
llen += BGP_LABEL_BYTES;
@@ -359,6 +362,9 @@ int bgp_nlri_parse_label(struct peer *peer, struct attr *attr,
memcpy(&addpath_id, pnt, BGP_ADDPATH_ID_LEN);
addpath_id = ntohl(addpath_id);
pnt += BGP_ADDPATH_ID_LEN;
+
+ if (pnt >= lim)
+ return BGP_NLRI_PARSE_ERROR_PACKET_OVERFLOW;
}
/* Fetch prefix length. */
@@ -377,6 +383,15 @@ int bgp_nlri_parse_label(struct peer *peer, struct attr *attr,
/* Fill in the labels */
llen = bgp_nlri_get_labels(peer, pnt, psize, &label);
+ if (llen == 0) {
+ flog_err(
+ EC_BGP_UPDATE_RCV,
+ "%s [Error] Update packet error (wrong label length 0)",
+ peer->host);
+ bgp_notify_send(peer, BGP_NOTIFY_UPDATE_ERR,
+ BGP_NOTIFY_UPDATE_INVAL_NETWORK);
+ return BGP_NLRI_PARSE_ERROR_LABEL_LENGTH;
+ }
p.prefixlen = prefixlen - BSIZE(llen);
/* There needs to be at least one label */

89
SOURCES/0020-CVE-2023-47234.patch Normal file
View File

@ -0,0 +1,89 @@
From c37119df45bbf4ef713bc10475af2ee06e12f3bf Mon Sep 17 00:00:00 2001
From: Donatas Abraitis <donatas@opensourcerouting.org>
Date: Sun, 29 Oct 2023 22:44:45 +0200
Subject: [PATCH] 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>
---
bgpd/bgp_attr.c | 19 ++++++++++---------
bgpd/bgp_attr.h | 1 +
bgpd/bgp_packet.c | 7 ++++++-
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
index 1473dc772502..75aa2ac7cce6 100644
--- a/bgpd/bgp_attr.c
+++ b/bgpd/bgp_attr.c
@@ -3399,15 +3399,6 @@ static int bgp_attr_check(struct peer *peer, struct attr *attr,
if (CHECK_FLAG(peer->cap, PEER_CAP_RESTART_RCV) && !attr->flag)
return BGP_ATTR_PARSE_PROCEED;
- /* "An UPDATE message that contains the MP_UNREACH_NLRI is not required
- to carry any other path attributes.", though if MP_REACH_NLRI or NLRI
- are present, it should. Check for any other attribute being present
- instead.
- */
- if ((!CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_MP_REACH_NLRI)) &&
- CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_MP_UNREACH_NLRI))))
- return BGP_ATTR_PARSE_PROCEED;
-
if (!CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_ORIGIN)))
type = BGP_ATTR_ORIGIN;
@@ -3426,6 +3417,16 @@ static int bgp_attr_check(struct peer *peer, struct attr *attr,
&& !CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_LOCAL_PREF)))
type = BGP_ATTR_LOCAL_PREF;
+ /* An UPDATE message that contains the MP_UNREACH_NLRI is not required
+ * to carry any other path attributes. Though if MP_REACH_NLRI or NLRI
+ * are present, it should. Check for any other attribute being present
+ * instead.
+ */
+ if (!CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_MP_REACH_NLRI)) &&
+ CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_MP_UNREACH_NLRI)))
+ return type ? BGP_ATTR_PARSE_MISSING_MANDATORY
+ : BGP_ATTR_PARSE_PROCEED;
+
/* If any of the well-known mandatory attributes are not present
* in an UPDATE message, then "treat-as-withdraw" MUST be used.
*/
diff --git a/bgpd/bgp_attr.h b/bgpd/bgp_attr.h
index fc347e7a1b4b..d30155e6dba0 100644
--- a/bgpd/bgp_attr.h
+++ b/bgpd/bgp_attr.h
@@ -364,6 +364,7 @@ enum bgp_attr_parse_ret {
*/
BGP_ATTR_PARSE_ERROR_NOTIFYPLS = -3,
BGP_ATTR_PARSE_EOR = -4,
+ BGP_ATTR_PARSE_MISSING_MANDATORY = -4,
} bgp_attr_parse_ret_t;
struct bpacket_attr_vec_arr;
diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
index a7514a26aa64..5dc35157ebf6 100644
--- a/bgpd/bgp_packet.c
+++ b/bgpd/bgp_packet.c
@@ -2359,7 +2359,12 @@ static int bgp_update_receive(struct peer_connection *connection,
/* Network Layer Reachability Information. */
update_len = end - stream_pnt(s);
- if (update_len) {
+ /* If we received MP_UNREACH_NLRI attribute, but also NLRIs, then
+ * NLRIs should be handled as a new data. Though, if we received
+ * NLRIs without mandatory attributes, they should be ignored.
+ */
+ if (update_len && attribute_len &&
+ attr_parse_ret != BGP_ATTR_PARSE_MISSING_MANDATORY) {
/* Set NLRI portion to structure. */
nlris[NLRI_UPDATE].afi = AFI_IP;
nlris[NLRI_UPDATE].safi = SAFI_UNICAST;

105
SOURCES/0021-CVE-2023-47235.patch Normal file
View File

@ -0,0 +1,105 @@
From 6814f2e0138a6ea5e1f83bdd9085d9a77999900b Mon Sep 17 00:00:00 2001
From: Donatas Abraitis <donatas@opensourcerouting.org>
Date: Fri, 27 Oct 2023 11:56:45 +0300
Subject: [PATCH] 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>
---
bgpd/bgp_attr.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/bgpd/bgp_attr.c b/bgpd/bgp_attr.c
index cf2dbe65b805..1473dc772502 100644
--- a/bgpd/bgp_attr.c
+++ b/bgpd/bgp_attr.c
@@ -3391,9 +3391,12 @@ static int bgp_attr_check(struct peer *peer, struct attr *attr,
uint8_t type = 0;
/* BGP Graceful-Restart End-of-RIB for IPv4 unicast is signaled as an
- * empty UPDATE. */
+ * empty UPDATE. 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.
+ */
if (CHECK_FLAG(peer->cap, PEER_CAP_RESTART_RCV) && !attr->flag)
- return BGP_ATTR_PARSE_PROCEED;
+ return BGP_ATTR_PARSE_WITHDRAW;
if (!CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_ORIGIN)))
type = BGP_ATTR_ORIGIN;
@@ -3273,7 +3276,13 @@ done:
aspath_unintern(&as4_path);
}
- if (ret != BGP_ATTR_PARSE_ERROR) {
+ /* If we received an UPDATE with mandatory attributes, then
+ * the unrecognized transitive optional attribute of that
+ * path MUST be passed. Otherwise, it's an error, and from
+ * security perspective it might be very harmful if we continue
+ * here with the unrecognized attributes.
+ */
+ if (ret == BGP_ATTR_PARSE_PROCEED) {
/* Finally intern unknown attribute. */
if (attr->transit)
attr->transit = transit_intern(attr->transit);

24
SPECS/frr.spec
View File

@ -7,7 +7,7 @@
Name: frr
Version: 7.5.1
Release: 13%{?checkout}%{?dist}
Release: 13%{?checkout}%{?dist}.3.alma.1
Summary: Routing daemon
License: GPLv2+
URL: http://www.frrouting.org
@ -54,7 +54,20 @@ Patch0011: 0011-reload-bfd-profile.patch
Patch0012: 0012-graceful-restart.patch
Patch0013: 0013-CVE-2022-37032.patch
Patch0014: 0014-bfd-profile-crash.patch
Patch0015: 0015-max-ttl-reload.patch
# https://git.almalinux.org/rpms/frr/raw/commit/7599d0ae96d0c1d1f42ae62e1f885ee58ed5b0cd/SOURCES/0010-CVE-2023-38802.patch
Patch0015: 0015-CVE-2023-38802.patch
# # https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0015-max-ttl-reload.patch
Patch0016: 0016-max-ttl-reload.patch
# https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0017-fix-crash-in-plist-update.patch
Patch0017: 0017-fix-crash-in-plist-update.patch
# https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0018-CVE-2023-38406.patch
Patch0018: 0018-CVE-2023-38406.patch
# https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0019-CVE-2023-38407.patch
Patch0019: 0019-CVE-2023-38407.patch
# https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0020-CVE-2023-47234.patch
Patch0020: 0020-CVE-2023-47234.patch
# https://gitlab.com/redhat/centos-stream/rpms/frr/-/blob/2dfcf2f37454302c56d8713db9d9d16e7d4d36d3/0021-CVE-2023-47235.patch
Patch0021: 0021-CVE-2023-47235.patch
%description
FRRouting is free software that manages TCP/IP based routing protocols. It takes
@ -275,6 +288,13 @@ make check PYTHON=%{__python3}
%endif
%changelog
* Fri Jan 12 2024 Andrew Lukoshko <alukoshko@almalinux.org> - 7.5.1-13.3.alma.1
- Resolves: RHEL-15916 - Flowspec overflow in bgpd/bgp_flowspec.c
- Resolves: RHEL-15919 - Out of bounds read in bgpd/bgp_label.c
- Resolves: RHEL-15869 - crash from specially crafted MP_UNREACH_NLRI-containing BGP UPDATE message
- Resolves: RHEL-15868 - crash from malformed EOR-containing BGP UPDATE message
- Resolves: RHEL-12039 - crash in plist update
* Tue Oct 10 2023 Michal Ruprich <mruprich@redhat.com> - 7.5.1-13
- Resolves: RHEL-2263 - eBGP multihop peer flapping due to delta miscalculation of new configuration