Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/link: problem with asan in combination with -X #56175

Closed
thanm opened this issue Oct 12, 2022 · 1 comment
Closed

cmd/link: problem with asan in combination with -X #56175

thanm opened this issue Oct 12, 2022 · 1 comment
Assignees
@cherrymui
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.20

Comments

@thanm
Copy link
Contributor

thanm commented Oct 12, 2022 •
edited
Loading

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

$ go version
go version devel go1.20-1d6b538862 Mon Oct 10 15:22:38 2022 -0400 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

linux/amd64

What did you do?

Unpack the attached tar file, then run "trystringmain.sh".

The Go program in the zip file contains two packages, "main" and "p". If you cd to "main" and run normally, works fine, e.g.

$ cd main
$ go run .
...
$ go run -asan .
...
$

However if you use "trystringmain.sh", it links the program with a series of "-X" options, the resulting program gets an asan error at runtime.

What did you expect to see?

Clean run with output of each string.

What did you see instead?

An asan error on the first string reference. Transcript:

+ cd main
...
+ go build -asan '-gcflags=-l -N' '-ldflags= -X=main.S1=abc -X=asan.bug/p.S1=abc -X=main.S2=abc1 -X=asan.bug/p.S2=abc1 -X=main.S3=abc12 -X=asan.bug/p.S3=abc12 -X=main.S4=abc123 -X=asan.bug/p.S4=abc123 -X=main.S5=abc1234 -X=asan.bug/p.S5=abc1234 -X=main.S6=abc12345 -X=asan.bug/p.S6=abc12345 -X=main.S7=abc123456 -X=asan.bug/p.S7=abc123456 -X=main.S8=abc1234567 -X=asan.bug/p.S8=abc1234567 -X=main.S9=abc12345678 -X=asan.bug/p.S9=abc12345678 -X=main.S10=abc123456789 -X=asan.bug/p.S10=abc123456789 -X=main.S11=abc12345678910 -X=asan.bug/p.S11=abc12345678910 -X=main.S12=abc1234567891011 -X=asan.bug/p.S12=abc1234567891011 -X=main.S13=abc123456789101112 -X=asan.bug/p.S13=abc123456789101112 -X=main.S14=abc12345678910111213 -X=asan.bug/p.S14=abc12345678910111213 -X=main.S15=abc1234567891011121314 -X=asan.bug/p.S15=abc1234567891011121314 -X=main.S16=abc123456789101112131415 -X=asan.bug/p.S16=abc123456789101112131415 -X=main.S17=abc12345678910111213141516 -X=asan.bug/p.S17=abc12345678910111213141516 -X=main.S18=abc1234567891011121314151617 -X=asan.bug/p.S18=abc1234567891011121314151617 -X=main.S19=abc123456789101112131415161718 -X=asan.bug/p.S19=abc123456789101112131415161718 -X=main.S20=abc12345678910111213141516171819 -X=asan.bug/p.S20=abc12345678910111213141516171819' stringmain.go
+ ./stringmain
String @0x5e33a0:
=================================================================
==1840783==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000005e33a0 at pc 0x00000052bb28 bp 0x000000000000 sp 0x10c00018dc18
READ of size 8 at 0x0000005e33a0 thread T0
    #0 0x52bb27 in main.pstring /tmp/asanbug/main/stringmain.go:14

0x0000005e33a0 is located 48 bytes to the left of global variable 'main.S12' defined in 'main' (0x5e33d0) of size 16
0x0000005e33a0 is located 32 bytes to the left of global variable 'main.S11' defined in 'main' (0x5e33c0) of size 16
0x0000005e33a0 is located 16 bytes to the left of global variable 'main.S10' defined in 'main' (0x5e33b0) of size 16
0x0000005e33a0 is located 0 bytes inside of global variable 'main.S1' defined in 'main' (0x5e33a0) of size 16
SUMMARY: AddressSanitizer: global-buffer-overflow /tmp/asanbug/main/stringmain.go:14 in main.pstring
Shadow bytes around the buggy address:
  0x0000800b4620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800b4630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800b4640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
  0x0000800b4650: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0000800b4660: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x0000800b4670: f9 f9 f9 f9[f9]f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0000800b4680: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0000800b4690: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0000800b46a0: f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800b46b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800b46c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1840783==ABORTING

What seems to be happening here is that at the point where the globals are compiled, the compiler is recording their sizes, however the linker is overriding the size due to the -X.

@thanm @lfolger @cherrymui

asanexample.zip
@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 12, 2022
@thanm thanm added this to the Go1.20 milestone Oct 12, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 12, 2022
@mknyszek mknyszek moved this to In Progress in Go Compiler / Runtime Oct 12, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/442635 mentions this issue: cmd/link: don't reset variable size when handling -X flag

Repository owner moved this from In Progress to Done in Go Compiler / Runtime Oct 13, 2022
romaindoumenc pushed a commit to TroutSoftware/go that referenced this issue Nov 3, 2022
@cherrymui @romaindoumenc
cmd/link: don't reset variable size when handling -X flag

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
Learn about vigilant mode
4c6b210 
The linker's -X flag allows setting/changing a string variable's
content at link time. Currently it resets its size then write a
new string header pointing to the new content. This mostly works.
But under ASAN build the string variable can have larger size
than the usual 2 words, due to the red zone. Resetting the size
can cause the variable to "overlap" (in ASAN's view) with other
variables. Don't reset the size.

Fixes golang#56175.

Change-Id: Ib364208201a7a2fd7f44f9b1797834198736a405
Reviewed-on: https://go-review.googlesource.com/c/go/+/442635
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
@golang golang locked and limited conversation to collaborators Oct 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@cherrymui cherrymui

Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
3 participants
@gopherbot @thanm @cherrymui