debug/dwarf: readType can stack overflow on deeply nested type chains

[artahir-dev]

Go version

go version go1.24.3 windows/amd64. Also verified present in tip (b5c2bd7) — src/debug/dwarf/type.go has had no depth-limit changes.

Output of go env in your module/workspace:

GOARCH="amd64"
GOOS="windows"
GOVERSION="go1.24.3"

What did you do?

Called (*dwarf.Data).Type() on a DWARF section containing a long linear chain of DW_TAG_typedef entries, each pointing to the next via DW_AT_type.

package main

import (
	"debug/dwarf"
	"encoding/binary"
	"fmt"
)

func main() {
	abbrev := []byte{
		0x01, 0x11, 0x01, 0x00, 0x00,
		0x02, 0x16, 0x00, 0x49, 0x13, 0x00, 0x00,
		0x03, 0x24, 0x00, 0x0b, 0x0b, 0x3e, 0x0b, 0x03, 0x08, 0x00, 0x00,
		0x00,
	}

	const depth = 1_000_000
	info := make([]byte, 0, 12+depth*5+8)
	var hdr [11]byte
	binary.LittleEndian.PutUint32(hdr[:4], uint32(16+depth*5))
	binary.LittleEndian.PutUint16(hdr[4:6], 2)
	hdr[10] = 4
	info = append(info, hdr[:]...)
	info = append(info, 0x01)
	for i := 0; i < depth; i++ {
		info = append(info, 0x02)
		var ref [4]byte
		if i < depth-1 {
			binary.LittleEndian.PutUint32(ref[:], uint32(12+(i+1)*5))
		} else {
			binary.LittleEndian.PutUint32(ref[:], uint32(12+depth*5))
		}
		info = append(info, ref[:]...)
	}
	info = append(info, 0x03, 4, 5, 'i', 'n', 't', 0, 0x00)

	d, _ := dwarf.New(abbrev, nil, nil, info, nil, nil, nil, nil)
	_, err := d.Type(12)
	fmt.Println(err)
}

What did you see happen?

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc020ce1480 stack=[0xc020ce0000, 0xc040ce0000]
fatal error: stack overflow

goroutine 1 [running]:
debug/dwarf.(*Data).readType(...)
        .../debug/dwarf/type.go:412
debug/dwarf.(*Data).readType.func3(...)
        .../debug/dwarf/type.go:485
debug/dwarf.(*Data).readType(...)
        .../debug/dwarf/type.go:809
debug/dwarf.(*Data).readType.func3(...)
        .../debug/dwarf/type.go:485
... (repeating)

What did you expect to see?

An error returned, not a fatal crash. readType calls itself recursively through the typeOf closure (type.go:485) with no depth counter. The typeCache map only prevents revisiting the same offset, so it stops cycles but not linear chains of distinct offsets.

go/parser had the same issue fixed in #53616 by adding a nestLev counter. The same approach would work here — add a depth parameter to readType and return a DecodeError when it exceeds a reasonable limit (e.g. 1000).

[gabyhelp]

Related Issues

• go/types: stack overflow in Alignof #71143
• debug/dwarf: DW_TAG_reference_type causes a panic when encountered by debug/dwarf #29601 (closed)
• x/tools/go/types/typeutil: stack overflow when hashing recursive embedded type interface #26863 (closed)
• go/types, types2: missing diagnosis for structs that contain themselves through type parameters #65711 (closed)
• encoding/gob: stack overflow #10415 (closed)
• runtime: stack traces of endless recursion should print top and bottom #7181 (closed)
• cmd/compile: stack overflow with a recursive type #22904 (closed)
• go/types, types2: stack overflow in hasVarSize for invalid type #48819 (closed)
• debug/dwarf: memory leak in dwarf parsing, entries remain on heap #72007 (closed)
• x/tools/go/types/objectpath: stack overflow trying to find inaccessible object in package with recursive interface #68046 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

It what situation would we run into chains like this?

[seankhliao]

We do have #47653 that says it shouldn't panic

[randall77]

(Note that this is a crash, not a panic. Not that it changes anything, other than the fact that the error is unrecoverable.)

With relation to #47653, I'm not sure debug/dwarf has anywhere close to the kind of hardening that that issue requests. It's coded to detect input corruption (especially things like truncated input), but not to deal with adversarial inputs. We can prevent this one problem, sure, but any user of this package is going to be susceptible to lots of other such issues. Nefarious dwarf info can cause all sorts of problems. Just as an example, if the dwarf info specifies a typedef type or array type whose element is itself, then the Size method on those types will enter an infinite recursion. (I haven't hacked up an example to actually do that, but I don't see any defenses against it in the code.)

If we really want to harden debug/dwarf against adversarial input, it will take a lot more than just this issue to achieve that.

[randall77]

@FiloSottile

[FiloSottile]

#47653 was from a time at which it looked like three out of four security reports were about parsers panic'ing or entering infinite loops or OOMing, which was taking up a lot of the security team's resources. That has not been the pattern for a while, so it might not be as much of a priority.

As for debug/dwarf, it has this text in the package doc

This package is not designed to be hardened against adversarial inputs, and is outside the scope of https://go.dev/security/policy. In particular, only basic validation is done when parsing object files. As such, care should be taken when parsing untrusted inputs, as parsing malformed files may consume significant resources, or cause panics.

so it looks like we made it official that it's not trying.

[ianlancetaylor]

That said, we've done a fair amount of work on debug/elf and friends to not panic or OOM, using packages like internal/saferio. But I agree that debug/dwarf is a harder problem.

[artahir-dev]

I understand that debug/dwarf isn’t meant to be hardened against adversarial input.

My point is just that this leads to an unrecoverable stack overflow rather than returning an error. A small depth guard in readType could prevent this specific crash with minimal complexity.

I’m not suggesting full hardening, only bounding the recursion to avoid a fatal runtime error.

[randall77]

Ok, if we're not talking adversarial input then my original question stands.

It what situation would we run into chains like this?

Who writes a typedef chain 1 million steps deep?