Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.

Excessive resource consumption when printing error string for host certificate validation in crypto/x509

Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The "#cgo pkg-config:" directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can provide a "--log-file" argument to this directive, causing pkg-config to write to an attacker-controlled location.

Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The "#cgo pkg-config:" directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can provide a "--log-file" argument to this directive, causing pkg-config to write to an attacker-controlled location.

Alan Coopersmith wrote in <01e3014e-85d8-484c-b755-bd8eb6ddd10d () oracle com>: |https://groups.google.com/g/golang-announce/c/Vd2tYVM8eUc announces: |> Hello gophers, |> |> We have just released Go versions 1.25.6 and 1.24.12, minor point \ |> releases. |> |> These releases include 6 security fixes following the security policy: |> |> - archive/zip: denial of service when parsing arbitrary ZIP archives |> |> archive/zip used a super-linear file name indexing algorithm \ |> that is invoked |> the first time a file in an archive is opened. This can lead \ |> to a denial of |> service when consuming a maliciously constructed ZIP archive. |> |> Thanks to Thanks to Jakub Ciolek for reporting this issue. |> |> This is CVE-2025-61728 and Go issue https://go.dev/issue/77102.

Go is thrilling you know, those personalities involved in the past and present (also including Plan9 history, and all that) ...

It is a little bit off-topic, but it reminds me of kinds of "detoriation", as well as "spreaded complication" i have introduced myself when fixing bugs of all sort. So looking at the link bug report, i see

for dir := path.Dir(name); dir != "."; dir = path.Dir(dir) {

being replaced with an unrolled

if idx := strings.LastIndex(dir, "/"); idx < 0 { ...

But Go supports "modification in place", and doesn't the above imply that the Go standard library interface is missing important functionality to avoid such security glitches in any code that makes use of path.? Ie, path.Dir() is

Dir returns all but the last element of path, typically the path's directory. After dropping the final element using Split, the path is Cleaned and trailing slashes are removed. If the path is empty, Dir returns ".". If the path consists entirely of slashes followed by non-slash bytes, Dir returns a single slash. In any other case, the returned path does not end in a slash.

and path.Split() is

Split splits path immediately following the final slash, separating it into a directory and file name component. If there is no slash in path, Split returns an empty dir and file set to path. The returned values have the property that path = dir+file.

And i note that the committed bugfix not only avoids all the canonicalization cleanup of Dir(), but also the creation of new (temporary) result strings. In order to do that creates (yet another?) place that fiddles with indices.

Just a (well-known, granted) thought in all the overdriven "memory-safe" noise.

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

An attacker can craft a malformed TIFF image which will consume a significant amount of memory when passed to DecodeConfig. This could lead to a denial of service.

The TIFF decoder does not place a limit on the size of compressed tile data. A maliciously-crafted image can exploit this to cause a small image (both in terms of pixel width/height, and encoded size) to make the decoder decode large amounts of compressed data, consuming excessive memory and CPU.

A maliciously-crafted image can cause excessive CPU consumption in decoding. A tiled image with a height of 0 and a very large width can cause excessive CPU consumption, despite the image size (width height) appearing to be zero.