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/_mD07VhyOGa?v=gotip

What did you expect to see?

The program finishing and printing Hello, without allocating too much

What did you see instead?

Running heap : 1769414080 that is 1.7 Bytes for a fix bytes input

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

Regression range is 2c46cc8:a2c2f06cad8aa722120cb73e965d168bfcb4d977

[catenacyber]

following #58754

[cagedmantis]

CC @golang/compiler, @ianlancetaylor

[bcmills]

The leading bytes seem to indicate that this is being parsed as an object file for plan9/386 (https://go.dev/play/p/pyCSYf-OioF).

(CC @golang/plan9)

[bcmills]

Just from inspecting the debug/buildinfo implementation, I suspect that the source of growth is here:
https://cs.opensource.google/go/go/+/master:src/debug/buildinfo/buildinfo.go;l=244;drc=b94dc384cabf75e7e8703265cd80f5324f84b642

Each of the ReadData implementations has a make call with a size given in a header, and it appears that few (none?) of the debug implementation validate the section sizes against the underlying file.

[gopherbot]

Change https://go.dev/cl/473657 mentions this issue: debug/buildinfo: use saferio in ReadData methods