If curl is told to use an HTTP proxy for a transfer with a non-HTTP(S) URL, it sets up the connection to the remote server by issuing a `CONNECT` request to the proxy, and then *tunnels* the rest of protocol through. An HTTP proxy might refuse this request (HTTP proxies often only allow outgoing connections to specific port numbers, like 443 for HTTPS) and instead return a non-200 respons code to the client. Due to flaws in the error/cleanup handling, this could trigger a double-free in curl if one of the following schemes were used in the URL for the transfer: `dict`, `gopher`, `gophers`, `ldap`, `ldaps`, `rtmp`, `rtmps`, `telnet` Reference: https://curl.se/docs/CVE-2022-42915.html
Created curl tracking bugs for this issue: Affects: fedora-all [bug 2138111] Created mingw-curl tracking bugs for this issue: Affects: fedora-all [bug 2138110]
This issue has been addressed in the following products: JBoss Core Services on RHEL 7 JBoss Core Services for RHEL 8 Via RHSA-2022:8840 https://access.redhat.com/errata/RHSA-2022:8840
This issue has been addressed in the following products: Red Hat JBoss Core Services Via RHSA-2022:8841 https://access.redhat.com/errata/RHSA-2022:8841
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2022-42915