Affected: AlmaLinux:9: go-toolset, AlmaLinux:9: golang, AlmaLinux:9: golang-bin, AlmaLinux:9: golang-docs, AlmaLinux:9: golang-misc, AlmaLinux:9: golang-src, AlmaLinux:9: golang-tests

The golang packages provide the Go programming language compiler.

Security Fix(es):

* golang-fips/openssl: Memory leaks in code encrypting and decrypting RSA payloads (CVE-2024-1394) * golang: net/http: memory exhaustion in Request.ParseMultipartForm (CVE-2023-45290) * golang: net/http/cookiejar: incorrect forwarding of sensitive headers and cookies on HTTP redirect (CVE-2023-45289) * golang: crypto/x509: Verify panics on certificates with an unknown public key algorithm (CVE-2024-24783) * golang: net/mail: comments in display names are incorrectly handled (CVE-2024-24784) * golang: html/template: errors returned from MarshalJSON methods may break template escaping (CVE-2024-24785) * golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS (CVE-2023-45288)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Affected: Alpaquita:23: go, Alpaquita:stream: go, BellSoft Hardened Containers:23: go, BellSoft Hardened Containers:stream: go

Affected: Bitnami: golang

When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.

When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.

When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.

Affected: openEuler:20.03-LTS-SP1: golang, openEuler:20.03-LTS-SP4: golang, openEuler:22.03-LTS: golang, openEuler:22.03-LTS-SP1: golang, openEuler:22.03-LTS-SP2: golang, openEuler:22.03-LTS-SP3: golang

The Go Programming Language. Security Fix(es): When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial domain, an http.Client does not forward sensitive headers such as "Authorization" or "Cookie". For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to bar.com will not. A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly forwarded.(CVE-2023-45289) When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.(CVE-2023-45290) Verifying a certificate chain which contains a certificate with an unknown public key algorithm will cause 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.(CVE-2024-24783) If errors returned from MarshalJSON methods contain us…

go1.22-1.22.1-1.1 on GA media

golang: net/http: golang: mime/multipart: golang: net/textproto: memory exhaustion in Request.ParseMultipartForm golang: crypto/x509: Verify panics on certificates with an unknown public key algorithm

Security update for go1.21

Affected: Ubuntu:14.04:LTS: golang-1.10, Ubuntu:Pro:16.04:LTS: golang-1.18, Ubuntu:16.04:LTS: golang-1.10, Ubuntu:16.04:LTS: golang-1.6, Ubuntu:Pro:16.04:LTS: golang-1.13, Ubuntu:18.04:LTS: golang-1.10, Ubuntu:Pro:18.04:LTS: golang-1.13, Ubuntu:Pro:18.04:LTS: golang-1.16, Ubuntu:Pro:18.04:LTS: golang-1.18, Ubuntu:18.04:LTS: golang-1.8 and 12 more

When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.

Ein Angreifer kann mehrere Schwachstellen in Golang Go ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.