跳转到帖子

ISHACK AI BOT

Members
  • 注册日期

  • 上次访问

ISHACK AI BOT 发布的所有帖子

  1. Debian: CVE-2023-29416: bzip3 -- security update Severity 7 CVSS (AV:N/AC:M/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description An issue was discovered in libbzip3.a in bzip3 before 1.3.0. A bz3_decode_block out-of-bounds write can occur with a crafted archive because bzip3 does not follow the required procedure for interacting with libsais. Solution(s) debian-upgrade-bzip3 References https://attackerkb.com/topics/cve-2023-29416 CVE - 2023-29416
  2. Debian: CVE-2023-24538: golang-1.19 -- security update Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) debian-upgrade-golang-1-19 References https://attackerkb.com/topics/cve-2023-24538 CVE - 2023-24538
  3. Debian: CVE-2023-29421: bzip3 -- security update Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description An issue was discovered in libbzip3.a in bzip3 before 1.2.3. There is an out-of-bounds write in bz3_decode_block. Solution(s) debian-upgrade-bzip3 References https://attackerkb.com/topics/cve-2023-29421 CVE - 2023-29421
  4. Red Hat OpenShift: CVE-2023-24538: golang: html/template: backticks not treated as string delimiters Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 06/15/2023 Added 06/15/2023 Modified 01/30/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) linuxrpm-upgrade-openstack-ironic linuxrpm-upgrade-python-flask References https://attackerkb.com/topics/cve-2023-24538 CVE - 2023-24538 RHSA-2023:3318 RHSA-2023:3319 RHSA-2023:3323 RHSA-2023:3366 RHSA-2023:3367 RHSA-2023:3445 RHSA-2023:3450 RHSA-2023:3455 RHSA-2023:3536 RHSA-2023:3540 RHSA-2023:3612 RHSA-2023:3624 RHSA-2023:3918 RHSA-2023:3943 RHSA-2023:4003 RHSA-2023:4093 RHSA-2023:4335 RHSA-2023:4470 RHSA-2023:4627 RHSA-2023:4657 RHSA-2023:4664 RHSA-2023:4986 RHSA-2023:5964 RHSA-2023:6346 RHSA-2023:6363 RHSA-2023:6402 RHSA-2023:6473 RHSA-2023:6474 RHSA-2023:6938 RHSA-2023:6939 RHSA-2024:0746 RHSA-2024:2944 View more
  5. Amazon Linux AMI: CVE-2023-24538: Security patch for amazon-ssm-agent ((Multiple Advisories)) Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/21/2023 Modified 01/28/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) amazon-linux-upgrade-amazon-ssm-agent amazon-linux-upgrade-golang References ALAS-2023-1866 CVE-2023-24538
  6. VMware Photon OS: CVE-2023-24536 Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2023-24536 CVE - 2023-24536
  7. Amazon Linux AMI: CVE-2023-24534: Security patch for golang (ALAS-2023-1731) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/21/2023 Modified 01/28/2025 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) amazon-linux-upgrade-golang References ALAS-2023-1731 CVE-2023-24534
  8. Huawei EulerOS: CVE-2023-24534: golang security update Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 07/10/2023 Added 07/10/2023 Modified 01/28/2025 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) huawei-euleros-2_0_sp9-upgrade-golang huawei-euleros-2_0_sp9-upgrade-golang-devel huawei-euleros-2_0_sp9-upgrade-golang-help References https://attackerkb.com/topics/cve-2023-24534 CVE - 2023-24534 EulerOS-SA-2023-2334
  9. Huawei EulerOS: CVE-2023-24537: golang security update Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 01/11/2024 Added 01/10/2024 Modified 01/28/2025 Description Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow. Solution(s) huawei-euleros-2_0_sp11-upgrade-golang huawei-euleros-2_0_sp11-upgrade-golang-devel huawei-euleros-2_0_sp11-upgrade-golang-help References https://attackerkb.com/topics/cve-2023-24537 CVE - 2023-24537 EulerOS-SA-2023-2686
  10. FreeBSD: (Multiple Advisories) (CVE-2023-24538): Grafana -- Critical vulnerability in golang Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/14/2023 Modified 01/28/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) freebsd-upgrade-package-go119 freebsd-upgrade-package-go120 freebsd-upgrade-package-grafana freebsd-upgrade-package-grafana8 freebsd-upgrade-package-grafana9 References CVE-2023-24538
  11. Huawei EulerOS: CVE-2023-24536: golang security update Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 01/11/2024 Added 01/10/2024 Modified 01/28/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) huawei-euleros-2_0_sp11-upgrade-golang huawei-euleros-2_0_sp11-upgrade-golang-devel huawei-euleros-2_0_sp11-upgrade-golang-help References https://attackerkb.com/topics/cve-2023-24536 CVE - 2023-24536 EulerOS-SA-2023-2686
  12. Huawei EulerOS: CVE-2023-24534: golang security update Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 01/11/2024 Added 01/10/2024 Modified 01/28/2025 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) huawei-euleros-2_0_sp11-upgrade-golang huawei-euleros-2_0_sp11-upgrade-golang-devel huawei-euleros-2_0_sp11-upgrade-golang-help References https://attackerkb.com/topics/cve-2023-24534 CVE - 2023-24534 EulerOS-SA-2023-2686
  13. CentOS Linux: CVE-2023-24537: Important: go-toolset and golang security update (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 10/24/2023 Added 10/23/2023 Modified 01/28/2025 Description Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow. Solution(s) centos-upgrade-aardvark-dns centos-upgrade-buildah centos-upgrade-buildah-debuginfo centos-upgrade-buildah-debugsource centos-upgrade-buildah-tests centos-upgrade-buildah-tests-debuginfo centos-upgrade-cockpit-podman centos-upgrade-conmon centos-upgrade-conmon-debuginfo centos-upgrade-conmon-debugsource centos-upgrade-container-selinux centos-upgrade-containernetworking-plugins centos-upgrade-containernetworking-plugins-debuginfo centos-upgrade-containernetworking-plugins-debugsource centos-upgrade-containers-common centos-upgrade-crit centos-upgrade-criu centos-upgrade-criu-debuginfo centos-upgrade-criu-debugsource centos-upgrade-criu-devel centos-upgrade-criu-libs centos-upgrade-criu-libs-debuginfo centos-upgrade-crun centos-upgrade-crun-debuginfo centos-upgrade-crun-debugsource centos-upgrade-delve centos-upgrade-delve-debuginfo centos-upgrade-delve-debugsource centos-upgrade-fuse-overlayfs centos-upgrade-fuse-overlayfs-debuginfo centos-upgrade-fuse-overlayfs-debugsource centos-upgrade-go-toolset centos-upgrade-golang centos-upgrade-golang-bin centos-upgrade-golang-docs centos-upgrade-golang-misc centos-upgrade-golang-race centos-upgrade-golang-src centos-upgrade-golang-tests centos-upgrade-libslirp centos-upgrade-libslirp-debuginfo centos-upgrade-libslirp-debugsource centos-upgrade-libslirp-devel centos-upgrade-netavark centos-upgrade-oci-seccomp-bpf-hook centos-upgrade-oci-seccomp-bpf-hook-debuginfo centos-upgrade-oci-seccomp-bpf-hook-debugsource centos-upgrade-podman centos-upgrade-podman-catatonit centos-upgrade-podman-catatonit-debuginfo centos-upgrade-podman-debuginfo centos-upgrade-podman-debugsource centos-upgrade-podman-docker centos-upgrade-podman-gvproxy centos-upgrade-podman-gvproxy-debuginfo centos-upgrade-podman-plugins centos-upgrade-podman-plugins-debuginfo centos-upgrade-podman-remote centos-upgrade-podman-remote-debuginfo centos-upgrade-podman-tests centos-upgrade-python3-criu centos-upgrade-python3-podman centos-upgrade-runc centos-upgrade-runc-debuginfo centos-upgrade-runc-debugsource centos-upgrade-skopeo centos-upgrade-skopeo-debuginfo centos-upgrade-skopeo-debugsource centos-upgrade-skopeo-tests centos-upgrade-slirp4netns centos-upgrade-slirp4netns-debuginfo centos-upgrade-slirp4netns-debugsource centos-upgrade-toolbox centos-upgrade-toolbox-debuginfo centos-upgrade-toolbox-debugsource centos-upgrade-toolbox-tests centos-upgrade-udica References CVE-2023-24537
  14. SUSE: CVE-2023-24538: SUSE Linux Security Advisory Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/10/2023 Modified 01/28/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) suse-upgrade-go1-19 suse-upgrade-go1-19-doc suse-upgrade-go1-19-race suse-upgrade-go1-20 suse-upgrade-go1-20-doc suse-upgrade-go1-20-race References https://attackerkb.com/topics/cve-2023-24538 CVE - 2023-24538
  15. CentOS Linux: CVE-2023-24534: Important: go-toolset and golang security update (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 10/24/2023 Added 10/23/2023 Modified 01/28/2025 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) centos-upgrade-aardvark-dns centos-upgrade-buildah centos-upgrade-buildah-debuginfo centos-upgrade-buildah-debugsource centos-upgrade-buildah-tests centos-upgrade-buildah-tests-debuginfo centos-upgrade-cockpit-podman centos-upgrade-conmon centos-upgrade-conmon-debuginfo centos-upgrade-conmon-debugsource centos-upgrade-container-selinux centos-upgrade-containernetworking-plugins centos-upgrade-containernetworking-plugins-debuginfo centos-upgrade-containernetworking-plugins-debugsource centos-upgrade-containers-common centos-upgrade-crit centos-upgrade-criu centos-upgrade-criu-debuginfo centos-upgrade-criu-debugsource centos-upgrade-criu-devel centos-upgrade-criu-libs centos-upgrade-criu-libs-debuginfo centos-upgrade-crun centos-upgrade-crun-debuginfo centos-upgrade-crun-debugsource centos-upgrade-delve centos-upgrade-delve-debuginfo centos-upgrade-delve-debugsource centos-upgrade-fuse-overlayfs centos-upgrade-fuse-overlayfs-debuginfo centos-upgrade-fuse-overlayfs-debugsource centos-upgrade-go-toolset centos-upgrade-golang centos-upgrade-golang-bin centos-upgrade-golang-docs centos-upgrade-golang-misc centos-upgrade-golang-race centos-upgrade-golang-src centos-upgrade-golang-tests centos-upgrade-grafana centos-upgrade-grafana-debuginfo centos-upgrade-grafana-debugsource centos-upgrade-libslirp centos-upgrade-libslirp-debuginfo centos-upgrade-libslirp-debugsource centos-upgrade-libslirp-devel centos-upgrade-netavark centos-upgrade-oci-seccomp-bpf-hook centos-upgrade-oci-seccomp-bpf-hook-debuginfo centos-upgrade-oci-seccomp-bpf-hook-debugsource centos-upgrade-podman centos-upgrade-podman-catatonit centos-upgrade-podman-catatonit-debuginfo centos-upgrade-podman-debuginfo centos-upgrade-podman-debugsource centos-upgrade-podman-docker centos-upgrade-podman-gvproxy centos-upgrade-podman-gvproxy-debuginfo centos-upgrade-podman-plugins centos-upgrade-podman-plugins-debuginfo centos-upgrade-podman-remote centos-upgrade-podman-remote-debuginfo centos-upgrade-podman-tests centos-upgrade-python3-criu centos-upgrade-python3-podman centos-upgrade-runc centos-upgrade-runc-debuginfo centos-upgrade-runc-debugsource centos-upgrade-skopeo centos-upgrade-skopeo-debuginfo centos-upgrade-skopeo-debugsource centos-upgrade-skopeo-tests centos-upgrade-slirp4netns centos-upgrade-slirp4netns-debuginfo centos-upgrade-slirp4netns-debugsource centos-upgrade-toolbox centos-upgrade-toolbox-debuginfo centos-upgrade-toolbox-debugsource centos-upgrade-toolbox-tests centos-upgrade-udica References CVE-2023-24534
  16. CentOS Linux: CVE-2023-24536: Important: go-toolset and golang security update (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 10/24/2023 Added 10/23/2023 Modified 01/28/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) centos-upgrade-aardvark-dns centos-upgrade-buildah centos-upgrade-buildah-debuginfo centos-upgrade-buildah-debugsource centos-upgrade-buildah-tests centos-upgrade-buildah-tests-debuginfo centos-upgrade-cockpit-podman centos-upgrade-conmon centos-upgrade-conmon-debuginfo centos-upgrade-conmon-debugsource centos-upgrade-container-selinux centos-upgrade-containernetworking-plugins centos-upgrade-containernetworking-plugins-debuginfo centos-upgrade-containernetworking-plugins-debugsource centos-upgrade-containers-common centos-upgrade-crit centos-upgrade-criu centos-upgrade-criu-debuginfo centos-upgrade-criu-debugsource centos-upgrade-criu-devel centos-upgrade-criu-libs centos-upgrade-criu-libs-debuginfo centos-upgrade-crun centos-upgrade-crun-debuginfo centos-upgrade-crun-debugsource centos-upgrade-delve centos-upgrade-delve-debuginfo centos-upgrade-delve-debugsource centos-upgrade-fuse-overlayfs centos-upgrade-fuse-overlayfs-debuginfo centos-upgrade-fuse-overlayfs-debugsource centos-upgrade-go-toolset centos-upgrade-golang centos-upgrade-golang-bin centos-upgrade-golang-docs centos-upgrade-golang-misc centos-upgrade-golang-race centos-upgrade-golang-src centos-upgrade-golang-tests centos-upgrade-libslirp centos-upgrade-libslirp-debuginfo centos-upgrade-libslirp-debugsource centos-upgrade-libslirp-devel centos-upgrade-netavark centos-upgrade-oci-seccomp-bpf-hook centos-upgrade-oci-seccomp-bpf-hook-debuginfo centos-upgrade-oci-seccomp-bpf-hook-debugsource centos-upgrade-podman centos-upgrade-podman-catatonit centos-upgrade-podman-catatonit-debuginfo centos-upgrade-podman-debuginfo centos-upgrade-podman-debugsource centos-upgrade-podman-docker centos-upgrade-podman-gvproxy centos-upgrade-podman-gvproxy-debuginfo centos-upgrade-podman-plugins centos-upgrade-podman-plugins-debuginfo centos-upgrade-podman-remote centos-upgrade-podman-remote-debuginfo centos-upgrade-podman-tests centos-upgrade-python3-criu centos-upgrade-python3-podman centos-upgrade-runc centos-upgrade-runc-debuginfo centos-upgrade-runc-debugsource centos-upgrade-skopeo centos-upgrade-skopeo-debuginfo centos-upgrade-skopeo-debugsource centos-upgrade-skopeo-tests centos-upgrade-slirp4netns centos-upgrade-slirp4netns-debuginfo centos-upgrade-slirp4netns-debugsource centos-upgrade-toolbox centos-upgrade-toolbox-debuginfo centos-upgrade-toolbox-debugsource centos-upgrade-toolbox-tests centos-upgrade-udica References CVE-2023-24536
  17. CentOS Linux: CVE-2023-24538: Important: go-toolset and golang security update (Multiple Advisories) Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 04/06/2023 Created 10/24/2023 Added 10/23/2023 Modified 01/28/2025 Description Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution. Solution(s) centos-upgrade-aardvark-dns centos-upgrade-buildah centos-upgrade-buildah-debuginfo centos-upgrade-buildah-debugsource centos-upgrade-buildah-tests centos-upgrade-buildah-tests-debuginfo centos-upgrade-cockpit-podman centos-upgrade-conmon centos-upgrade-conmon-debuginfo centos-upgrade-conmon-debugsource centos-upgrade-container-selinux centos-upgrade-containernetworking-plugins centos-upgrade-containernetworking-plugins-debuginfo centos-upgrade-containernetworking-plugins-debugsource centos-upgrade-containers-common centos-upgrade-crit centos-upgrade-criu centos-upgrade-criu-debuginfo centos-upgrade-criu-debugsource centos-upgrade-criu-devel centos-upgrade-criu-libs centos-upgrade-criu-libs-debuginfo centos-upgrade-crun centos-upgrade-crun-debuginfo centos-upgrade-crun-debugsource centos-upgrade-delve centos-upgrade-delve-debuginfo centos-upgrade-delve-debugsource centos-upgrade-fuse-overlayfs centos-upgrade-fuse-overlayfs-debuginfo centos-upgrade-fuse-overlayfs-debugsource centos-upgrade-go-toolset centos-upgrade-golang centos-upgrade-golang-bin centos-upgrade-golang-docs centos-upgrade-golang-misc centos-upgrade-golang-race centos-upgrade-golang-src centos-upgrade-golang-tests centos-upgrade-libslirp centos-upgrade-libslirp-debuginfo centos-upgrade-libslirp-debugsource centos-upgrade-libslirp-devel centos-upgrade-netavark centos-upgrade-oci-seccomp-bpf-hook centos-upgrade-oci-seccomp-bpf-hook-debuginfo centos-upgrade-oci-seccomp-bpf-hook-debugsource centos-upgrade-podman centos-upgrade-podman-catatonit centos-upgrade-podman-catatonit-debuginfo centos-upgrade-podman-debuginfo centos-upgrade-podman-debugsource centos-upgrade-podman-docker centos-upgrade-podman-gvproxy centos-upgrade-podman-gvproxy-debuginfo centos-upgrade-podman-plugins centos-upgrade-podman-plugins-debuginfo centos-upgrade-podman-remote centos-upgrade-podman-remote-debuginfo centos-upgrade-podman-tests centos-upgrade-python3-criu centos-upgrade-python3-podman centos-upgrade-runc centos-upgrade-runc-debuginfo centos-upgrade-runc-debugsource centos-upgrade-skopeo centos-upgrade-skopeo-debuginfo centos-upgrade-skopeo-debugsource centos-upgrade-skopeo-tests centos-upgrade-slirp4netns centos-upgrade-slirp4netns-debuginfo centos-upgrade-slirp4netns-debugsource centos-upgrade-toolbox centos-upgrade-toolbox-debuginfo centos-upgrade-toolbox-debugsource centos-upgrade-toolbox-tests centos-upgrade-udica References CVE-2023-24538
  18. Red Hat OpenShift: CVE-2023-24536: golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 06/15/2023 Added 06/15/2023 Modified 01/28/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) linuxrpm-upgrade-conmon linuxrpm-upgrade-cri-o linuxrpm-upgrade-microshift linuxrpm-upgrade-openshift-clients linuxrpm-upgrade-podman linuxrpm-upgrade-skopeo References https://attackerkb.com/topics/cve-2023-24536 CVE - 2023-24536 RHSA-2023:3167 RHSA-2023:3318 RHSA-2023:3319 RHSA-2023:3367 RHSA-2023:3445 RHSA-2023:3450 RHSA-2023:3455 RHSA-2023:3536 RHSA-2023:3540 RHSA-2023:3612 RHSA-2023:3624 RHSA-2023:3918 RHSA-2023:3943 RHSA-2023:4003 RHSA-2023:4093 RHSA-2023:4335 RHSA-2023:4470 RHSA-2023:4627 RHSA-2023:4657 RHSA-2023:4664 RHSA-2023:4986 RHSA-2023:5964 RHSA-2023:6346 RHSA-2023:6363 RHSA-2023:6402 RHSA-2023:6473 RHSA-2023:6474 RHSA-2023:6938 RHSA-2023:6939 RHSA-2024:2944 View more
  19. Amazon Linux AMI: CVE-2023-24537: Security patch for golang ((Multiple Advisories)) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/21/2023 Modified 01/28/2025 Description Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow. Solution(s) amazon-linux-upgrade-golang References ALAS-2023-1848 CVE-2023-24537
  20. SUSE: CVE-2023-24534: SUSE Linux Security Advisory Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/10/2023 Modified 01/28/2025 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) suse-upgrade-go1-19 suse-upgrade-go1-19-doc suse-upgrade-go1-19-race suse-upgrade-go1-20 suse-upgrade-go1-20-doc suse-upgrade-go1-20-race References https://attackerkb.com/topics/cve-2023-24534 CVE - 2023-24534
  21. SUSE: CVE-2023-24536: SUSE Linux Security Advisory Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/10/2023 Modified 01/28/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) suse-upgrade-go1-19 suse-upgrade-go1-19-doc suse-upgrade-go1-19-race suse-upgrade-go1-20 suse-upgrade-go1-20-doc suse-upgrade-go1-20-race References https://attackerkb.com/topics/cve-2023-24536 CVE - 2023-24536
  22. Amazon Linux AMI: CVE-2023-24536: Security patch for golang (ALAS-2023-1731) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 04/21/2023 Modified 01/28/2025 Description Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. Solution(s) amazon-linux-upgrade-golang References ALAS-2023-1731 CVE-2023-24536
  23. Alpine Linux: CVE-2023-24537: Integer Overflow or Wraparound Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow. Solution(s) alpine-linux-upgrade-go References https://attackerkb.com/topics/cve-2023-24537 CVE - 2023-24537 https://security.alpinelinux.org/vuln/CVE-2023-24537
  24. Alpine Linux: CVE-2023-24534: Uncontrolled Resource Consumption Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers. Solution(s) alpine-linux-upgrade-go alpine-linux-upgrade-nomad alpine-linux-upgrade-traefik References https://attackerkb.com/topics/cve-2023-24534 CVE - 2023-24534 https://security.alpinelinux.org/vuln/CVE-2023-24534
  25. Ubuntu: (Multiple Advisories) (CVE-2023-24537): Go vulnerabilities Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/06/2023 Created 05/05/2023 Added 05/01/2023 Modified 01/28/2025 Description Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow. Solution(s) ubuntu-pro-upgrade-golang-1-13 ubuntu-pro-upgrade-golang-1-13-go ubuntu-pro-upgrade-golang-1-13-src ubuntu-pro-upgrade-golang-1-16 ubuntu-pro-upgrade-golang-1-16-go ubuntu-pro-upgrade-golang-1-16-src ubuntu-pro-upgrade-golang-1-18 ubuntu-pro-upgrade-golang-1-18-go ubuntu-pro-upgrade-golang-1-18-src ubuntu-pro-upgrade-golang-1-19 ubuntu-pro-upgrade-golang-1-19-go ubuntu-pro-upgrade-golang-1-19-src ubuntu-pro-upgrade-golang-1-20 ubuntu-pro-upgrade-golang-1-20-go ubuntu-pro-upgrade-golang-1-20-src References https://attackerkb.com/topics/cve-2023-24537 CVE - 2023-24537 USN-6038-1 USN-6038-2 USN-6140-1