debug/buildinfo: over allocation

[catenacyber]

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/root/.go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/root/.go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/src/ngolo-fuzzing/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2481516251=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run https://go.dev/play/p/MrXFx8gd3pK?v=gotip

What did you expect to see?

The program finishing and printing Hello, without allocating too much

What did you see instead?

Nothing : Program exited

Found by https://github.com/catenacyber/ngolo-fuzzing with oss-fuzz :
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58290

[catenacyber]

Like #58886

[ianlancetaylor]

I think that this is the debug/pe version of #54967. After a long discussion in https://go.dev/cl/429601, we decided to return an error for attempts to read the content of a BSS section. We should probably do the same here. CC @ZekeLu @aarzilli @kortschak in case they have any thoughts.

[kortschak]

I can't reproduce this failure either on go1.19 or tip (go1.21-3f987ae61d).

[ianlancetaylor]

I can see it with this variant of the program:

package main

import (
	"bytes"
	"debug/buildinfo"
        "fmt"
        "runtime"
)

func main() {
	_, err := buildinfo.Read(bytes.NewReader([]byte{0x4d, 0x5a, 0x64, 0x65, 0x61, 0x64, 0x74, 0x54, 0x59, 0x50, 0x45, 0x0, 0x0, 0x0, 0x0, 0x5, 0x0, 0x3a, 0x64, 0x65, 0x70, 0x9, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x6c, 0x79, 0x4d, 0x69, 0x28, 0xff, 0x20, 0x44, 0x20, 0xb8, 0x63, 0x4f, 0x85, 0x7e, 0xff, 0x1, 0x81, 0x69, 0x6b, 0x0, 0x0, 0x52, 0x6b, 0x6c, 0x4e, 0x6f, 0x53, 0x69, 0x64, 0x9, 0x0, 0x0, 0x0, 0x60, 0x0, 0x0, 0x0, 0x28, 0x6b, 0x6c, 0x4e, 0x6f, 0x3b, 0x53, 0xff, 0x3c, 0x0, 0x5d, 0x6d, 0x6f, 0x64, 0x9, 0x3, 0x79, 0x16, 0x32, 0x23, 0x8, 0x44, 0x7e, 0x61, 0x74, 0x68, 0x9, 0x0, 0x53, 0x0, 0x0, 0x0, 0x0, 0x9, 0x0, 0x5d, 0x40, 0x1, 0x0, 0x0, 0x6c, 0x69, 0x73, 0x74, 0x20, 0x7b, 0xa, 0x7d, 0xa, 0x6c, 0x69, 0x73, 0xff, 0x20, 0x7b, 0xff, 0x20, 0x47, 0x6f, 0x20, 0x62, 0x75, 0x69, 0x6c, 0x64, 0x69, 0x6e, 0x66, 0x3a, 0x8, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7e, 0x1b, 0xa, 0x0, 0x0, 0x0, 0x0, 0x0, 0x6, 0x89, 0x7f, 0x7d, 0x2c, 0x6c, 0x69, 0x73, 0x0, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0xb, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x9f, 0x0, 0x0, 0x0, 0x62, 0x75, 0x69, 0x6c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7e, 0x0, 0x34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x44, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2e, 0x2e, 0x78, 0x78, 0x78, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3f, 0x72, 0x72, 0x72, 0x5c, 0x22, 0x5c, 0x6e, 0x20, 0x20, 0x7d, 0x5c, 0x6e, 0x75, 0x69, 0x6c, 0x69, 0x73, 0x74, 0x20, 0x28, 0x28, 0x7d, 0x5c, 0x6e, 0x6c, 0x0, 0x0, 0x0, 0x0, 0xa, 0x20, 0x20}))
	fmt.Println(err)
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	fmt.Printf("%#x\n", m.TotalAlloc)
}

For me this prints 0x1080bfbb8 which is unreasonably large.

[kortschak]

Yeah, looking past the failure to crash, I see this. The issue is exactly as you describe. Here there is a progressive allocation via saferio of 788546460 bytes.

[kortschak]

The MS docs say that when PointerToRawData (Offset in the SectionHeader) is 0, it is indicative of uninitialised data:

The file pointer to the first page of the section within the COFF file. For executable images, this must be a multiple of FileAlignment from the optional header. For object files, the value should be aligned on a 4-byte boundary for best performance. When a section contains only uninitialized data, this field should be zero.

This could be made use of in the same way that SHT_NOBITS is in elf to make a nobits reader instead of the allocation.

[gopherbot]

Change https://go.dev/cl/488475 mentions this issue: debug/pe: return error on reading from section with uninitialized data