SIGSEGV when using go source analysis

[Quince-Pie]

When scanning the current HEAD of: https://github.com/kubernetes/dashboard (1d4897cd8d1c4af8747906c87f11acbb598814b9)

Environment: osv-scanner version: 1.7.0 OS: NixOS and Debian go version: go1.21.7 linux/amd64

Output:

Scanning dir .
Scanning /tmp/dashboard/ at commit 1d4897cd8d1c4af8747906c87f11acbb598814b9
Scanned /tmp/dashboard/modules/api/go.mod file and found 84 packages
Scanned /tmp/dashboard/modules/auth/go.mod file and found 66 packages
Scanned /tmp/dashboard/modules/common/certificates/go.mod file and found 18 packages
Scanned /tmp/dashboard/modules/common/client/go.mod file and found 43 packages
Scanned /tmp/dashboard/modules/common/csrf/go.mod file and found 29 packages
Scanned /tmp/dashboard/modules/common/errors/go.mod file and found 20 packages
Scanned /tmp/dashboard/modules/common/helpers/go.mod file and found 16 packages
Scanned /tmp/dashboard/modules/common/tools/go.mod file and found 248 packages
Scanned /tmp/dashboard/modules/common/types/go.mod file and found 16 packages
Scanned /tmp/dashboard/modules/metrics-scraper/go.mod file and found 64 packages
Scanned /tmp/dashboard/modules/web/go.mod file and found 67 packages
Scanning directory for vendored libs: /tmp/dashboard/modules/web/src/common/components/endpoint/external
Scanned /tmp/dashboard/modules/web/yarn.lock file and found 1759 packages
Filtered 19 local package/s from the scan.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x12f731a]

goroutine 2393 [running]:
golang.org/x/tools/go/ssa.memberFromObject(0xc016d23480, {0x0, 0x0?}, {0x0, 0x0}, {0x0, 0x0})
	golang.org/x/[email protected]/go/ssa/create.go:55 +0x5a
golang.org/x/tools/go/ssa.membersFromDecl(0xc016d23480, {0x197bf80?, 0xc014c02980?}, {0x164737c, 0x6})
	golang.org/x/[email protected]/go/ssa/create.go:178 +0x16b
golang.org/x/tools/go/ssa.(*Program).CreatePackage(0xc0110cc8f0, 0xc0132e0000, {0xc0132087f8, 0x3, 0x3}, 0xc0110c0550, 0x0)
	golang.org/x/[email protected]/go/ssa/create.go:250 +0x86e
golang.org/x/vuln/internal/vulncheck.buildSSA({0xc0168f8b58, 0x1, 0xc003a75f90?}, 0xc000b7ec40)
	golang.org/x/[email protected]/internal/vulncheck/utils.go:54 +0x45a
golang.org/x/vuln/internal/vulncheck.source.func1()
	golang.org/x/[email protected]/internal/vulncheck/source.go:54 +0x8f
created by golang.org/x/vuln/internal/vulncheck.source in goroutine 283
	golang.org/x/[email protected]/internal/vulncheck/source.go:52 +0x28e

[another-rex]

Hmm... it looks like it might be related to: https://github.com/golang/go/issues/65590.

For now the workaround would be to disable go call analysis on these projects while we try to fix this:

osv-scanner --no-call-analysis=go <path-to-scan>

[oliverchang]

CC @zpavlinovic

[zpavlinovic]

I was able to reproduce the issue with the govulncheck command. It seems the crash happens in api module (the offending package is k8s.io/dashboard/csrf). I will look deeper into this.

Though, I can reproduce the issue on my linux/amd64 machine only when govulncheck is built with go1.21 and I analyze the module under go1.22. When govulncheck is built with go1.22, I cannot reproduce the issue.

[picatz]

FWIW, we were experiencing the same problem for the hashicorp/boundary repository.

Boundary is using 1.22, but our analysis (using the SSA package) was built with 1.21 and was panicing the same way as reported for osv-scanner and govulncheck. Updating to 1.22 resolved the issue on our end.

So it seems the SSA package (latest version and older versions from what I could tell) is not able to analyze code using 1.22 if 1.21 was used to build the analyzer.

[zpavlinovic]

This issue is due to a slight breakage of Go forward-compatibility promises: semantics for loops starting at go1.22 is not compatible with go1.21 and earlier. The only true fix is to rebuild govulncheck with the newer Go versions. govulncheck also reports a more useful error message instead of a crash.

More info can be found here.

[oliverchang]

@another-rex What do we need to do on the OSV-Scanner side to resolve this?

I suppose we need to upgrade to Go 1.22 and re-release?

[another-rex]

I believe this is fixed on the latest versions of osv-scanner, tested on 1.7.4