debug/buildinfo: don't crash on corrupt object file

If the length reported for the object file is more than the amount of
data we actually read, then the count can tell us that there is
sufficient remaining data but the slice operation can fail.

No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.

Fixes #69066

Change-Id: I8d12ca8ade3330517ade45c7578b477772b7efd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/608517
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

diff --git a/src/debug/buildinfo/buildinfo.go b/src/debug/buildinfo/buildinfo.go
index f3d38b26e84af9701fdfb579979c74decbbee4be..07f835127ecde7a4ec8a3c269b69fbf5e7c0eda6 100644 (file)
--- a/src/debug/buildinfo/buildinfo.go
+++ b/src/debug/buildinfo/buildinfo.go
@@ -380,7 +380,14 @@ func searchMagic(x exe, start, size uint64) (uint64, error) {
                        }
                        if i%buildInfoAlign != 0 {
                                // Found magic, but misaligned. Keep searching.
-                               data = data[(i+buildInfoAlign-1)&^(buildInfoAlign-1):]
+                               next := (i + buildInfoAlign - 1) &^ (buildInfoAlign - 1)
+                               if next > len(data) {
+                                       // Corrupt object file: the remaining
+                                       // count says there is more data,
+                                       // but we didn't read it.
+                                       return 0, errNotGoExe
+                               }
+                               data = data[next:]
                                continue
                        }
                        // Good match!