-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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.
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
syscall,x/sys/unix: ptrace wrappers erroneously pass Go pointers as type uintptr #58387
Comments
Change https://go.dev/cl/465676 mentions this issue: |
In CL 419915, both pointer fields of the PtraceIoDesc struct were converted to type uintptr to address golang/go#54113. However, that change was overzealous: the fix needed to convert fields that refer to addresses in the child process, but the Addr field of PtraceIoDesc is not even in the child process! It is instead an address in the parent (Go) process. Go's unsafe.Pointer rules prohibit converting a Go pointer to a uintptr except when immediately converting back to an unsafe.Pointer or calling a system call. Populating a PtraceIoDesc struct is neither of those things, so converting the Addr field to uintptr introduced a use-after-free bug. This change reverts the change to the Addr field from CL 419915 and consolidates the implementation of PtraceIO to reduce the the amount of code that varies with GOARCH. This change does not address the remaining ptrace uintptr bug (golang/go#58387), which is also present in the Linux implementation. Fixes golang/go#58351. Updates golang/go#54113. For golang/go#41205. Change-Id: I14bdb4af42130aa7b4375e3f53fd1a0435f14307 Reviewed-on: https://go-review.googlesource.com/c/sys/+/465676 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
In triage, @bcmills are you currently working on this? Assigned it to you for now but feel free to unassign. |
I am not actively working on it, but I'm happy to advise and do code reviews. (It should be straightforward plumbing, but will require regenerating and/or carefully editing generated files for a lot of different platforms) |
Change https://go.dev/cl/469835 mentions this issue: |
The existing ptrace wrapper accepts pointer argument as an uintptr which often points to the memory allocated in Go. This violates unsafe.Pointer safety rules. For golang/go#58387 Change-Id: Ib3b4c50368725191f0862c6c7c6d46b0568523c7 Reviewed-on: https://go-review.googlesource.com/c/sys/+/469835 Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
Change https://go.dev/cl/470299 mentions this issue: |
Change https://go.dev/cl/526455 mentions this issue: |
Change https://go.dev/cl/526475 mentions this issue: |
ptracePtr was introduced in CL 469835 for darwin but it's not used on this platform. Also, the argument types for addr and data were swapped in the generated ptrace1Ptr (probably because the change was not generated but done manually). This change also includes generated changes moving some definitions in zsyscall_darwin_*.go and removing some empty lines in zsyscall_darwin_*.s. These changes result from running ./mkall on darwin/amd64 and darwin/arm64. For golang/go#58387 Change-Id: I90bba3be7fbc8c77815450d0b666a2948b63fab0 Reviewed-on: https://go-review.googlesource.com/c/sys/+/526455 Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
ptracePtr was introduced in CL 470299 for darwin but it's not used on this platform. Also, the argument types for addr and data were swapped in the generated ptrace1Ptr (probably because the change was not generated but done manually). For #58387 Change-Id: I429ab0c741e19020d98729c34efabce1d9003f56 Reviewed-on: https://go-review.googlesource.com/c/go/+/526475 Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change https://go.dev/cl/527535 mentions this issue: |
ptracePtr was introduced in CL 470299 for openbsd but it's not used on this platform. For #58387 Change-Id: I27901c3f4497e18dc407a9248b66e2691c9a6abb Reviewed-on: https://go-review.googlesource.com/c/go/+/527535 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
The
unsafe.Pointer
rules allow “conversion of aPointer
to auintptr
when callingsyscall.Syscall
”, with a caveat:The
ptrace
wrappers on both Linux and FreeBSD violate that requirement. They pass auintptr
argument to theptrace
helper function, which is what ultimately callssyscall.Syscall
, and the arguments to theptrace
helper often do point to buffers allocated in Go:x/sys
: https://cs.opensource.google/search?q=%5Cbptrace%5C(.*,%5C%20uintptr%5C(unsafe%5C.Pointer%5C(.*%5C)%5C)&sq=&ss=go%2Fx%2Fsyssyscall
: https://cs.opensource.google/search?q=%5Cbptrace%5Ba-z0-9%5D*%5C(.*,%5C%20uintptr%5C(unsafe%5C.Pointer%5C(.*%5C)%5C)%20-filepath:src%2Fcmd%2Fvendor&sq=&ss=go%2FgoThese issues appear to date all the way back to 2009: the
ptrace
wrapper function was added in commit 9df5287 (CC @aclements), and in CL 126960043 which copied that pattern tox/sys
.The
ptrace
function likely needs a split like the one done forioctl
in #44834.(attn @golang/runtime; CC @ianlancetaylor @bradfitz @tklauser)
The text was updated successfully, but these errors were encountered: