aboutsummaryrefslogtreecommitdiffstats
path: root/meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch
diff options
context:
space:
mode:
Diffstat (limited to 'meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch')
-rw-r--r--meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch98
1 files changed, 98 insertions, 0 deletions
diff --git a/meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch b/meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch
new file mode 100644
index 0000000000..9bf63372a4
--- /dev/null
+++ b/meta-networking/recipes-protocols/frr/frr/CVE-2023-47234.patch
@@ -0,0 +1,98 @@
+From 682f100cd8d1bf7510939faa033f69ce64f965e9 Mon Sep 17 00:00:00 2001
+From: Donatas Abraitis <donatas@opensourcerouting.org>
+Date: Mon, 20 Nov 2023 14:32:38 +0000
+Subject: [PATCH 5/6] 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>
+
+CVE: CVE-2023-47234
+
+Upstream-Status: Backport [https://github.com/FRRouting/frr/commit/c37119df45bbf4ef713bc10475af2ee06e12f3bf]
+
+Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
+---
+ 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 35122943e..13da27e99 100644
+--- a/bgpd/bgp_attr.c
++++ b/bgpd/bgp_attr.c
+@@ -3055,15 +3055,6 @@ static int bgp_attr_check(struct peer *peer, struct attr *attr,
+ !length)
+ 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;
+
+@@ -3082,6 +3073,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 69f962134..77640dd5b 100644
+--- a/bgpd/bgp_attr.h
++++ b/bgpd/bgp_attr.h
+@@ -378,6 +378,7 @@ typedef enum {
+ /* only used internally, send notify + convert to BGP_ATTR_PARSE_ERROR
+ */
+ BGP_ATTR_PARSE_ERROR_NOTIFYPLS = -3,
++ 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 261695198..c1c28f344 100644
+--- a/bgpd/bgp_packet.c
++++ b/bgpd/bgp_packet.c
+@@ -1767,7 +1767,12 @@ static int bgp_update_receive(struct peer *peer, bgp_size_t size)
+ /* Network Layer Reachability Information. */
+ update_len = end - stream_pnt(s);
+
+- if (update_len && attribute_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;
+--
+2.40.0