golang/go · error

invalid pointers found in go:fipsinfo

Error message

invalid pointers found in go:fipsinfo

What it means

While finalizing a binary, the Go linker computes a FIPS-140 integrity hash by walking the `go:fipsinfo` symbol, which holds start/end pointer pairs delimiting the code/data regions that must be hashed. After applying the relocation delta, every (start,end) pair must lie entirely inside one registered output section (text, rodata, etc.). If no section fully contains a pair, the linker cannot certify the binary's integrity and aborts rather than emit an un-verifiable image.

Source

Thrown at src/cmd/link/internal/ld/fips140.go:588

		return fmt.Errorf("corrupt pointer found in go:fipsinfo")
	}
	delta := peself - self

Addrs:
	for i := 0; i < 4; i++ {
		start := int64(uptr(data[0:])) + delta
		end := int64(uptr(data[ctxt.Arch.PtrSize:])) + delta
		data = data[2*ctxt.Arch.PtrSize:]
		for _, sect := range pf.Sections {
			if int64(sect.VirtualAddress) <= start && start <= end && end <= int64(sect.VirtualAddress)+int64(sect.Size) {
				off := int64(sect.Offset) - int64(sect.VirtualAddress)
				if err := f.addSection(start+off, end+off); err != nil {
					return err
				}
				continue Addrs
			}
		}
		return fmt.Errorf("invalid pointers found in go:fipsinfo")
	}

	// Overwrite the go:fipsinfo sum field with the calculated sum.
	if _, err := wf.WriteAt(f.sum(), int64(sect.Offset)+off+fipsMagicLen); err != nil {
		return err
	}
	if err := wf.Close(); err != nil {
		return err
	}
	return f.Close()
}

View on GitHub (pinned to b6b368adc5)

Solutions

  1. Run `go clean -cache` then rebuild — a stale cache after a toolchain upgrade is the most common cause.
  2. Ensure every package (including cgo C objects) is compiled with the exact same Go version and GOEXPERIMENT setting.
  3. Remove custom `-extldflags` linker scripts and `-T` section-layout flags; let the linker choose the default layout.
  4. If using `-overlay` or modified runtime sources, disable FIPS mode (`GOEXPERIMENT=noboringcrypto`) or restore the unmodified `crypto/internal/fips140` sources.
  5. File a bug against the Go toolchain if the error persists with a clean cache and stock flags — it indicates the fipsinfo symbol's pointers legitimately do not match the output sections.

Example fix

# before
GOFLAGS=-tags=fips140 go build -ldflags='-extldflags -T custom.lds' ./...

# after
go clean -cache
GOFLAGS=-tags=fips140 go build ./...
Defensive patterns

Strategy: fallback

Validate before calling

# Ensure no mixed toolchain versions in the build
GO_VERSION=$(go version)
find . -name '*.o' -o -name '*.a' | xargs -r file | grep -v "$GO_VERSION" || echo 'objects consistent'

# Verify fipsinfo symbol exists and is well-formed in a test build
go build -o /tmp/check_bin ./... && objdump -t /tmp/check_bin | grep fipsinfo

Try / catch

# In CI, link and fall back to a clean rebuild on fips failure
set +e
go build -o bin/app ./...
rc=$?
set -e
if [ $rc -ne 0 ]; then
  echo 'link failed; attempting clean rebuild'
  go clean -cache
  go build -a -o bin/app ./...
fi

Prevention

When it happens

Trigger: Triggered at link time when building with FIPS-enabled crypto (GOEXPERIMENT=boringcrypto or `GOFLAGS=-tags=fips140`) and the section layout is non-standard: custom external linker scripts (`-ldflags='-extldflags -T ...'`), `-cover`/`-race` instrumentation that inserts extra sections, `-overlay` builds, or object files compiled by a mismatched Go toolchain version that emit a different fipsinfo shape.

Common situations: Mixing `.o`/`.a` artifacts from different Go versions in one build cache; using a hand-rolled linker script with cgo; a stale or corrupted build cache after a Go upgrade; building with experimental flags that relocate sections the fips pass does not know about.

Related errors

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/191f36f505cb49ba. Report an issue: GitHub.