ospfd: Solved crash in RI parsing with OSPF TE #15674

odd22 · 2024-04-03T14:35:53Z

Iggy Frankovic discovered another ospfd crash when perfomring fuzzing of OSPF LSA packets. The crash occurs in ospf_te_parse_ri() function when attemping to read Segment Routing subTLVs. The original code doesn't check if the size of the SR subTLVs have the correct length. In presence of erronous LSA, this will cause a buffer overflow and ospfd crash.

This patch introduces new verification of the subTLVs size for Router Information TLV.

aceelindem

See a couple questions on RFC 8665 parsing.

aceelindem · 2024-04-03T14:57:21Z

ospfd/ospf_te.c

@@ -2456,6 +2456,8 @@ static int ospf_te_parse_ri(struct ls_ted *ted, struct ospf_lsa *lsa)

 		switch (ntohs(tlvh->type)) {
 		case RI_SR_TLV_SR_ALGORITHM:
+			if (TLV_BODY_SIZE(tlvh) != ALGORITHM_COUNT)


The number of algorithms is variable - right? Why must there be 4? Shouldn't this be "< 1"?

Good Catch. In fact I need that the size is comprise between 1 and 4.

Just update the code to check that Algorithm size is in the interval [1 - 4]. Normally, 2 should be sufficient according to RFC8665 as only 2 algorithms have been defines (SPF and Strict SPF). This should be modified when Flex algo will be added latter.

aceelindem · 2024-04-03T14:58:24Z

ospfd/ospf_te.c

@@ -2456,6 +2456,8 @@ static int ospf_te_parse_ri(struct ls_ted *ted, struct ospf_lsa *lsa)

 		switch (ntohs(tlvh->type)) {


Shouldn't all these checks break out if the size isn't the minimum, i.e., "< minimum" rather than "!=".

Well, yes and no. Yes when subTLV has variable size like you mention about the Algorithm, and no when subTLVs have fixed size. I'll check with SRGB, SRLB and MSD in which category they felt and change code accordingly.

SRGB and SRLB are fixed size today (RFC 8665) but could be extended with Sub-TLVs in future RFCs. This seems unlikely but I may be overlooking something. MSD allows for multiple MSD types today (RFC 8476). What I would do if it could be done without too much effort is just ignore values that aren't understood. However, I don't feel that strongly.

As per RFC8665,

Only a single SID/Label Sub-TLV MAY be advertised in the SID/Label Range TLV. If more than one SID/Label Sub-TLV is present, the SID/Label Range TLV MUST be ignored.

Thus, the size should not be exceeded 12 bytes. If there is more than one SID/Label Sub-TLV, the code MUST ignore the SRGB (or SRLB). Thus, but checking that the TLV size is exactly 12, we ensure that there is only one SID/Label Sub-TLV and that the SRGB or SRLB is acceptable. Regarding the size of the SID/Label sub-TLVs size, it could be 3 or 4 depending if the SID is an MPLS label (3 bytes) or an index (4 bytes). But, in any case, due to the fact that OSPF impose a 4 bytes alignment of TLV, there is an extra byte when SID is an MPLS label. Thus, in all case, from the SRGB or SRLB TLV point of view, the SID/Label SubTLV has already the same size and conduct to a TLV of 12 bytes. Again, if there new RFCs that extend SRGB / SRLB, we'll modify the code accordingly. For the moment, the code is supporting strictly RFC8665, not more.

Regarding MSD, as per RFC8476:

When multiple Node MSD TLVs are received from a given router, the
receiver MUST use the first occurrence of the TLV in the Router
Information (RI) LSA.

In addition, as per RFC8491, only one Node MSD Type has been defined. Thus, only one Node MSD is pertinent and supported. So, checking that there is one Node MSD and not more is correct. Again, if new RFC defin new MSD Type in the registry, we'll enhance the code. However, I changed the code to check that Node MSD size is not lower than the expected size as you purpose.

odd22 · 2024-04-05T13:27:24Z

Update the code accordingly to the review and add a new commit for Extended Link LSA parser

aceelindem

See the comment on the remote interface address.

aceelindem · 2024-04-05T16:57:26Z

ospfd/ospf_te.c

@@ -2744,6 +2753,13 @@ static int ospf_te_parse_ext_link(struct ls_ted *ted, struct ospf_lsa *lsa)

 	/* Initialize TLV browsing */
 	len = TLV_BODY_SIZE(&ext->header) - EXT_TLV_LINK_SIZE;
+	i = lsa->size - (OSPF_LSA_HEADER_SIZE + TLV_HDR_SIZE);


This check is ok since RFC 3630 indicates in section 2.4.2:

Only one Link TLV shall be carried in each LSA, allowing for fine
granularity changes in topology.

You might want to add a comment stating this.

aceelindem · 2024-04-05T17:09:09Z

ospfd/ospf_te.c

@@ -2753,6 +2769,8 @@ static int ospf_te_parse_ext_link(struct ls_ted *ted, struct ospf_lsa *lsa)

 		switch (ntohs(tlvh->type)) {
 		case EXT_SUBTLV_ADJ_SID:
+			if (TLV_BODY_SIZE(tlvh) != EXT_SUBTLV_ADJ_SID_SIZE)


Ok - this will work since TLV_BODY_SIZE() rounds up to the 4 byte boundary so it doesn't matter whether a local label or offset is advertised as specified in section 5 of RFC 8665.

Yes. That's the purpose of the TLV_BODY_SIZE() macro. In fact, all TLV_ macros are dealing with the 4 bytes alignment.

aceelindem · 2024-04-05T17:13:42Z

ospfd/ospf_te.c

@@ -2808,6 +2828,8 @@ static int ospf_te_parse_ext_link(struct ls_ted *ted, struct ospf_lsa *lsa)

 			break;
 		case EXT_SUBTLV_RMT_ITF_ADDR:
+			if (TLV_BODY_SIZE(tlvh) != EXT_SUBTLV_RMT_ITF_ADDR_SIZE)


RFC 3630 allows for multiple remote addresses in section 2.5.4 of RFC 3630.

Well, this is not part of the RFC3630. In fact, this subTLV is a Cisco proprietary one using the experimental type 32768. From what I could observed on Cisco router, I saw only one remote IP address. If you have some Cisco internal documents that explain this TLV, please share them to us.

Okay this is the OSPF Extended Link Opaque LSA. What confused me is that this is a general purpose LSA rather than a TE LSA.

aceelindem · 2024-04-05T17:19:07Z

ospfd/ospf_te.c

@@ -2456,6 +2456,9 @@ static int ospf_te_parse_ri(struct ls_ted *ted, struct ospf_lsa *lsa)

 		switch (ntohs(tlvh->type)) {
 		case RI_SR_TLV_SR_ALGORITHM:
+			if (TLV_BODY_SIZE(tlvh) < 1
+			    || TLV_BODY_SIZE(tlvh) > ALGORITHM_COUNT)


Shouldn't you remove this check and only retain the first ALGORITHM_COUNT?

Well, the goal is to check that there is a valid size to avoid a problem in case of malformed LSA, DDoS ... that Iggy detected with fuzzing. Thus, I prefer to keep the control to let the code more robust.

My point was that RFC 8665 section 3.1 doesn't limit the number of algorithms advertised to 4. What you could do is parse all that are advertised and only retain the algorithms that are known to the implementation since those are the only ones that would make a difference. See https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

riw777

no comments further than @aceelindem 's ...

aceelindem

Let's go ahead with this - while I would have allowed for the full extent of the sub-TLVs as allowed in the standards, I agree that the probability of these being advertised today is minimal.

odd22 · 2024-04-09T15:35:55Z

Let's go ahead with this - while I would have allowed for the full extent of the sub-TLVs as allowed in the standards, I agree that the probability of these being advertised today is minimal.

The main goal of this PR is to enhance the original code to prevent ospfd crash against malformed LSA. Not to enhance or add new RFCs or features. We could discuss offline the list of improvement we need to add to ospfd.

ton31337 · 2024-04-14T17:43:08Z

Could you fix frrbot styling issues before merging?

odd22 · 2024-04-16T15:25:49Z

Could you fix frrbot styling issues before merging?

Done

odd22 · 2024-05-22T15:55:35Z

ci:rerun

odd22 · 2024-05-22T19:59:04Z

ci:run

aceelindem · 2024-05-22T21:36:47Z

Got the error this time. The problem comes from a wrong TLV size verification for TE database which output the ospf_te_parse_pref() and ospf_te_parse_link() with error. Unfortunately, within ospf opaque processing, if a registered function terminate with error, others registered functions in the queue are not call (see lines 1043 - 1045 in ospf_opaque.c). Thus, Opaque LSA for Segment Routing are not processed and thus, tests failed as MPLS table is not fulfill.

Hope the tests pass this time.

So, this was an intermittant failure? The changes in the 3 recent commits all add more checking - which change fixed the failing topotests? I can't find any checking that was corrected (only added validation). What am I missing?

aceelindem · 2024-05-22T21:39:28Z

Got the error this time. The problem comes from a wrong TLV size verification for TE database which output the ospf_te_parse_pref() and ospf_te_parse_link() with error. Unfortunately, within ospf opaque processing, if a registered function terminate with error, others registered functions in the queue are not call (see lines 1043 - 1045 in ospf_opaque.c). Thus, Opaque LSA for Segment Routing are not processed and thus, tests failed as MPLS table is not fulfill.
Hope the tests pass this time.

So, this was an intermittant failure? The changes in the 3 recent commits all add more checking - which change fixed the failing topotests? I can't find any checking that was corrected (only added validation). What am I missing?

Was this causing the topotest failures?

if (IPV4_NET0(attr.standard.local.s_addr) && !attr.standard.local_id) {
ote_debug(" |- Found no TE Link local address/ID. Abort!");
return -1;
}

Currently zebra does not deny the routes if `ip protocol <proto> route-map FOO` commmand is configured with reference to an undefined route-map (FOO in this case). However, on FRR restart, in zebra_route_map_check() routes get denied if route-map name is available but the route-map is not defined. This change was introduced in fd303a4. Fix: When `ip protocol <proto> route-map FOO` CLI is configured with reference to an undefined route-map FOO, let the processing in ip_protocol_rm_add() and ip_protocol_rm_del() go through so that zebra can deny the routes instead of simply returning. This will result in consistent behavior. Testing Done: Before fix: ``` spine-1# configure spine-1(config)# ip protocol bgp route-map rmap7 root@spine-1:mgmt:/var/home/cumulus# vtysh -c "show run" | grep rmap7 ip protocol bgp route-map rmap7 root@spine-1:mgmt:/var/home/cumulus# spine-1(config)# do show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric, Z - FRR, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure C>* 27.0.0.1/32 is directly connected, lo, 02:27:45 B>* 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1, weight 1, 02:27:35 B>* 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2, weight 1, 02:27:40 B>* 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3, weight 1, 02:27:40 B>* 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4, weight 1, 02:27:40 ``` After fix: ``` spine-1(config)# ip protocol bgp route-map route-map67 spine-1(config)# do show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric, Z - FRR, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure C>* 27.0.0.1/32 is directly connected, lo, 00:35:03 B 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1 inactive, weight 1, 00:34:58 B 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2 inactive, weight 1, 00:34:57 B 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3 inactive, weight 1, 00:34:57 B 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4 inactive, weight 1, 00:34:58 spine-1(config)# root@spine-1:mgmt:/var/home/cumulus# ip route show root@spine-1:mgmt:/var/home/cumulus# ``` Signed-off-by: Pooja Jagadeesh Doijode <[email protected]>

Iggy Frankovic discovered another ospfd crash when performing fuzzing of OSPF LSA packets. The crash occurs in ospf_te_parse_ri() function when attemping to read Segment Routing subTLVs. The original code doesn't check if the size of the SR subTLVs have the correct length. In presence of erronous LSA, this will cause a buffer overflow and ospfd crash. This patch introduces new verification of the subTLVs size for Router Information TLV. Co-authored-by: Iggy Frankovic <[email protected]> Signed-off-by: Olivier Dugeon <[email protected]>

Iggy Frankovic discovered another ospfd crash when performing fuzzing of OSPF LSA packets. The crash occurs in ospf_te_parse_ext_link() function when attemping to read Segment Routing Adjacency SID subTLVs. The original code doesn't check if the size of the Extended Link TLVs and subTLVs have the correct length. In presence of erronous LSA, this will cause a buffer overflow and ospfd crashes. This patch introduces new verification of the subTLVs size for Extended Link TLVs and subTLVs. Similar check has been also introduced for the Extended Prefix TLV. Co-authored-by: Iggy Frankovic <[email protected]> Signed-off-by: Olivier Dugeon <[email protected]>

During fuzzing, Iggy Frankovic discovered that get_edge() function in ospf_te.c could return null pointer, in particular when the link_id or advertised router IP addresses are fuzzed. As the null pointer returned by get_edge() function is not handlei by calling functions, this could cause ospfd crash. This patch introduces new verification of returned pointer by get_edge() function and stop the processing in case of null pointer. In addition, link ID and advertiser router ID are validated before calling ls_find_edge_by_key() to avoid the creation of a new edge with an invalid key. CVE-2024-34088 Co-authored-by: Iggy Frankovic <[email protected]> Signed-off-by: Olivier Dugeon <[email protected]>

odd22 · 2024-05-24T14:16:05Z

So, this was an intermittant failure? The changes in the 3 recent commits all add more checking - which change fixed the failing topotests? I can't find any checking that was corrected (only added validation). What am I missing?

The previous versions of my PR were wrong and cause systematic crashed. It is not intermittent.

odd22 · 2024-05-24T14:24:12Z

So, this was an intermittant failure? The changes in the 3 recent commits all add more checking - which change fixed the failing topotests? I can't find any checking that was corrected (only added validation). What am I missing?

Was this causing the topotest failures?

if (IPV4_NET0(attr.standard.local.s_addr) && !attr.standard.local_id) {
ote_debug(" |- Found no TE Link local address/ID. Abort!");
return -1;
}

Let me try to explain how Opaque LSA is handle. Within ospfd/ospf_opaque.c there is a mechanism to register specific functions for a given type of Opaque LSA. The current ospfd code handle 4 different Opaque LSA: TE, Router Information, Extended Prefix and Extended Link. All of them have a different LSA-ID starting respectively by 1.x.x.x, 4.x.x.x, 7.x.x.x and 8.x.x.x. For each of them, specifics functions are registered in ospf_opaque handler. Look at the beginning of ospf_te.c, ospf_ri.c and ospf_ext.c.

Now, within ospf opaque processing, if a registered function terminated with error, others registered functions in the queue are not call (see lines 1043 - 1045 in ospf_opaque.c). Regarding the current code and how configuration file is parsed, TE and RI functions are registered before Extended ones. Thus, if a TE or RI function failed during opaque handler, the Extended registered functions are not called which cause tests failure, in particular tests which uses Segment Routing.

Thus, if we would change how opaque registered functions are handled in case of error, we need to discuss pro/cons of the current system and produce another PR.

Hope these explanation are clear.

aceelindem · 2024-05-24T19:20:49Z

So, this was an intermittant failure? The changes in the 3 recent commits all add more checking - which change fixed the failing topotests? I can't find any checking that was corrected (only added validation). What am I missing?
Was this causing the topotest failures?

if (IPV4_NET0(attr.standard.local.s_addr) && !attr.standard.local_id) { ote_debug(" |- Found no TE Link local address/ID. Abort!"); return -1; }

Let me try to explain how Opaque LSA is handle. Within ospfd/ospf_opaque.c there is a mechanism to register specific functions for a given type of Opaque LSA. The current ospfd code handle 4 different Opaque LSA: TE, Router Information, Extended Prefix and Extended Link. All of them have a different LSA-ID starting respectively by 1.x.x.x, 4.x.x.x, 7.x.x.x and 8.x.x.x. For each of them, specifics functions are registered in ospf_opaque handler. Look at the beginning of ospf_te.c, ospf_ri.c and ospf_ext.c.

Now, within ospf opaque processing, if a registered function terminated with error, others registered functions in the queue are not call (see lines 1043 - 1045 in ospf_opaque.c). Regarding the current code and how configuration file is parsed, TE and RI functions are registered before Extended ones. Thus, if a TE or RI function failed during opaque handler, the Extended registered functions are not called which cause tests failure, in particular tests which uses Segment Routing.

Thus, if we would change how opaque registered functions are handled in case of error, we need to discuss pro/cons of the current system and produce another PR.

Hope these explanation are clear.

Yes - I understand and I agree the OSPF opaque infra-structure shouldn't be so fragile.

Jafaral · 2024-05-24T19:29:34Z

@Mergifyio backport stable/8.4 stable/8.5 stable/9.0 stable/9.1 stable/10.0

mergify · 2024-05-24T19:29:40Z

backport stable/8.4 stable/8.5 stable/9.0 stable/9.1 stable/10.0

✅ Backports have been created

#16088 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) has been created for branch stable/8.4
#16087 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) has been created for branch stable/8.5
#16086 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) has been created for branch stable/9.0
#16085 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) has been created for branch stable/9.1
#16084 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) has been created for branch stable/10.0

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

…4_8.5 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

frrbot bot added the ospf label Apr 3, 2024

github-actions bot added master size/XS labels Apr 3, 2024

aceelindem reviewed Apr 3, 2024

View reviewed changes

odd22 force-pushed the ospfd-te branch from d57e8e0 to e51b42c Compare April 5, 2024 12:57

github-actions bot added size/S and removed size/XS labels Apr 5, 2024

odd22 force-pushed the ospfd-te branch from e51b42c to c3d0a2c Compare April 5, 2024 13:26

frrbot bot added bgp bugfix isis tests Topotests, make check, etc zebra labels Apr 5, 2024

github-actions bot added size/M and removed size/S labels Apr 5, 2024

odd22 force-pushed the ospfd-te branch from c3d0a2c to 344fb4b Compare April 5, 2024 13:28

github-actions bot added size/S and removed size/M labels Apr 5, 2024

aceelindem reviewed Apr 5, 2024

View reviewed changes

odd22 force-pushed the ospfd-te branch from 344fb4b to b911c5b Compare April 9, 2024 11:48

github-actions bot added size/M and removed size/S labels Apr 9, 2024

riw777 approved these changes Apr 9, 2024

View reviewed changes

aceelindem approved these changes Apr 9, 2024

View reviewed changes

odd22 force-pushed the ospfd-te branch from b911c5b to 34d704f Compare April 16, 2024 14:53

odd22 removed isis zebra labels May 22, 2024

Pdoijode and others added 4 commits May 23, 2024 10:46

odd22 force-pushed the ospfd-te branch from 1c9268a to 8c177d6 Compare May 23, 2024 08:47

frrbot bot added the zebra label May 23, 2024

thillux mentioned this pull request May 23, 2024

frr: 9.1 -> 10.0 NixOS/nixpkgs#304232

Merged

13 tasks

Jafaral merged commit 52703f0 into FRRouting:master May 24, 2024
11 checks passed

donaldsharp added a commit that referenced this pull request May 25, 2024

Merge pull request #16084 from FRRouting/mergify/bp/stable/10.0/pr-15674

e1170c6

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

donaldsharp added a commit that referenced this pull request May 25, 2024

Merge pull request #16085 from FRRouting/mergify/bp/stable/9.1/pr-15674

9237991

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

donaldsharp added a commit that referenced this pull request May 25, 2024

Merge pull request #16086 from FRRouting/mergify/bp/stable/9.0/pr-15674

051d129

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

donaldsharp added a commit that referenced this pull request May 25, 2024

Merge pull request #16088 from FRRouting/mergify/bp/stable/8.4/pr-15674

7636c65

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

ton31337 mentioned this pull request May 28, 2024

ospfd: Solved crash in RI parsing with OSPF TE (backport #15674) #16096

Merged

donaldsharp added a commit that referenced this pull request May 29, 2024

Merge pull request #16096 from opensourcerouting/fix/backport_pr_1567…

07bd3ee

…4_8.5 ospfd: Solved crash in RI parsing with OSPF TE (backport #15674)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ospfd: Solved crash in RI parsing with OSPF TE #15674

ospfd: Solved crash in RI parsing with OSPF TE #15674

odd22 commented Apr 3, 2024

aceelindem left a comment

aceelindem Apr 3, 2024

odd22 Apr 4, 2024

odd22 Apr 5, 2024

aceelindem Apr 3, 2024

odd22 Apr 4, 2024 •

edited

Loading

aceelindem Apr 4, 2024

odd22 Apr 5, 2024 •

edited

Loading

odd22 commented Apr 5, 2024

aceelindem left a comment

aceelindem Apr 5, 2024

odd22 Apr 9, 2024

aceelindem Apr 5, 2024

odd22 Apr 9, 2024

aceelindem Apr 5, 2024

odd22 Apr 9, 2024

aceelindem Apr 9, 2024

aceelindem Apr 5, 2024

odd22 Apr 9, 2024

aceelindem Apr 9, 2024

riw777 left a comment

aceelindem left a comment •

edited

Loading

odd22 commented Apr 9, 2024

ton31337 commented Apr 14, 2024

odd22 commented Apr 16, 2024

odd22 commented May 22, 2024

odd22 commented May 22, 2024

aceelindem commented May 22, 2024

aceelindem commented May 22, 2024

odd22 commented May 24, 2024 •

edited

Loading

odd22 commented May 24, 2024

aceelindem commented May 24, 2024

Jafaral commented May 24, 2024

mergify bot commented May 24, 2024 •

edited

Loading

		@@ -2456,6 +2456,8 @@ static int ospf_te_parse_ri(struct ls_ted ted, struct ospf_lsa lsa)

		switch (ntohs(tlvh->type)) {

ospfd: Solved crash in RI parsing with OSPF TE #15674

ospfd: Solved crash in RI parsing with OSPF TE #15674

Conversation

odd22 commented Apr 3, 2024

aceelindem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odd22 Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odd22 Apr 5, 2024 • edited Loading

Choose a reason for hiding this comment

odd22 commented Apr 5, 2024

aceelindem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

riw777 left a comment

Choose a reason for hiding this comment

aceelindem left a comment • edited Loading

Choose a reason for hiding this comment

odd22 commented Apr 9, 2024

ton31337 commented Apr 14, 2024

odd22 commented Apr 16, 2024

odd22 commented May 22, 2024

odd22 commented May 22, 2024

aceelindem commented May 22, 2024

aceelindem commented May 22, 2024

odd22 commented May 24, 2024 • edited Loading

odd22 commented May 24, 2024

aceelindem commented May 24, 2024

Jafaral commented May 24, 2024

mergify bot commented May 24, 2024 • edited Loading

✅ Backports have been created

odd22 Apr 4, 2024 •

edited

Loading

odd22 Apr 5, 2024 •

edited

Loading

aceelindem left a comment •

edited

Loading

odd22 commented May 24, 2024 •

edited

Loading

mergify bot commented May 24, 2024 •

edited

Loading