|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * migration_toolkit_for_containers/mtc-release-notes.adoc |
| 4 | +:_mod-docs-content-type: REFERENCE |
| 5 | +[id="migration-mtc-release-notes-1-7-16_{context}"] |
| 6 | += {mtc-full} 1.7.16 release notes |
| 7 | + |
| 8 | +[id="resolved-issues-1-7-16_{context}"] |
| 9 | +== Resolved issues |
| 10 | + |
| 11 | +This release has the following resolved issues: |
| 12 | + |
| 13 | +.CVE-2023-45290: Golang: `net/http`: Memory exhaustion in the `Request.ParseMultipartForm` method |
| 14 | + |
| 15 | +A flaw was found in the `net/http` Golang standard library package, which impacts earlier versions of {mtc-short}. When parsing a `multipart` form, either explicitly with `Request.ParseMultipartForm` or implicitly with `Request.FormValue`, `Request.PostFormValue`, or `Request.FormFile` methods, limits on the total size of the parsed form are not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing long lines to cause the allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. |
| 16 | + |
| 17 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 18 | + |
| 19 | +For more details, see link:https://access.redhat.com/security/cve/CVE-2023-45290[CVE-2023-45290] |
| 20 | + |
| 21 | +.CVE-2024-24783: Golang: `crypto/x509`: Verify panics on certificates with an unknown public key algorithm |
| 22 | + |
| 23 | +A flaw was found in the `crypto/x509` Golang standard library package, which impacts earlier versions of {mtc-short}. Verifying a certificate chain that contains a certificate with an unknown public key algorithm causes `Certificate.Verify` to panic. This affects all `crypto/tls` clients and servers that set `Config.ClientAuth` to `VerifyClientCertIfGiven` or `RequireAndVerifyClientCert`. The default behavior is for TLS servers to not verify client certificates. |
| 24 | + |
| 25 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 26 | + |
| 27 | +For more details, see link:https://access.redhat.com/security/cve/cve-2024-24783[CVE-2024-24783]. |
| 28 | + |
| 29 | +.CVE-2024-24784: Golang: `net/mail`: Comments in display names are incorrectly handled |
| 30 | + |
| 31 | +A flaw was found in the `net/mail` Golang standard library package, which impacts earlier versions of {mtc-short}. The `ParseAddressList` function incorrectly handles comments, text in parentheses, and display names. As this is a misalignment with conforming address parsers, it can result in different trust decisions being made by programs using different parsers. |
| 32 | + |
| 33 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 34 | + |
| 35 | +For more details, see link:https://access.redhat.com/security/cve/cve-2024-24784[CVE-2024-24784]. |
| 36 | + |
| 37 | +.CVE-2024-24785: Golang: `html/template`: Errors returned from `MarshalJSON` methods may break template escaping |
| 38 | + |
| 39 | +A flaw was found in the `html/template` Golang standard library package, which impacts earlier versions of {mtc-short}. If errors returned from `MarshalJSON` methods contain user-controlled data, they could be used to break the contextual auto-escaping behavior of the `html/template` package, allowing subsequent actions to inject unexpected content into templates. |
| 40 | + |
| 41 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 42 | + |
| 43 | +For more details, see link:https://access.redhat.com/security/cve/cve-2024-24785[CVE-2024-24785]. |
| 44 | + |
| 45 | +.CVE-2024-29180: `webpack-dev-middleware`: Lack of URL validation may lead to file leak |
| 46 | + |
| 47 | +A flaw was found in the `webpack-dev-middleware package`, which impacts earlier versions of {mtc-short}. This flaw fails to validate the supplied URL address sufficiently before returning local files, which could allow an attacker to craft URLs to return arbitrary local files from the developer's machine. |
| 48 | + |
| 49 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 50 | + |
| 51 | +For more details, see link:https://access.redhat.com/security/cve/cve-2024-29180[CVE-2024-29180]. |
| 52 | + |
| 53 | +.CVE-2024-30255: `envoy`: HTTP/2 CPU exhaustion due to CONTINUATION frame flood |
| 54 | + |
| 55 | +A flaw was found in how the `envoy` proxy implements the HTTP/2 codec, which impacts earlier versions of {mtc-short}. There are insufficient limitations placed on the number of `CONTINUATION` frames that can be sent within a single stream, even after exceeding the header map limits of `envoy`. This flaw could allow an unauthenticated remote attacker to send packets to vulnerable servers. These packets could consume compute resources and cause a denial of service (DoS). |
| 56 | + |
| 57 | +To resolve this issue, upgrade to {mtc-short} 1.7.16. |
| 58 | + |
| 59 | +For more details, see link:https://access.redhat.com/security/cve/cve-2024-30255[CVE-2024-30255]. |
| 60 | + |
| 61 | + |
| 62 | +[id="known-issues-1-7-16_{context}"] |
| 63 | +== Known issues |
| 64 | + |
| 65 | +This release has the following known issues: |
| 66 | + |
| 67 | +.Direct Volume Migration is failing as the Rsync pod on the source cluster goes into an `Error` state |
| 68 | + |
| 69 | +On migrating any application with a Persistent Volume Claim (PVC), the `Stage` migration operation succeeds with warnings, but the Direct Volume Migration (DVM) fails with the `rsync` pod on the source namespace moving into an `error` state. link:https://bugzilla.redhat.com/show_bug.cgi?id=2256141[(BZ#2256141)] |
| 70 | + |
| 71 | +.The conflict condition is briefly cleared after it is created |
| 72 | + |
| 73 | +When creating a new state migration plan that returns a conflict error message, the error message is cleared very shortly after it is displayed. link:https://bugzilla.redhat.com/show_bug.cgi?id=2144299[(BZ#2144299)] |
| 74 | + |
| 75 | +.Migration fails when there are multiple Volume Snapshot Locations of different provider types configured in a cluster |
| 76 | + |
| 77 | +When there are multiple Volume Snapshot Locations (VSLs) in a cluster with different provider types, but you have not set any of them as the default VSL, Velero results in a validation error that causes migration operations to fail. link:https://bugzilla.redhat.com/show_bug.cgi?id=2180565[(BZ#2180565)] |
0 commit comments