net: slice bounds out of range #61060
Comments
|
I believe it has something to do with DNS over UDP over IPv6. I can reproduce it by running: While using the Mullvad VPN. I suspect even if it's an edge case and the packet is being intercepted, it shouldn't be panicking my application. |
I can run this command without error on linux/amd64, platform related issue? |
The relevant block of code (in That would seem to imply that at that point
Unfortunately, the most plausible explanations both seem unlikely:
The latter possibility makes me think of #60449, but note that that is for But the fact that this reproduces for you “[w]hile using the Mullvad VPN” makes me wonder if something about the VPN is causing the libc (CC @ianlancetaylor, @golang/runtime) |
bcmills
added
OS-Darwin
NeedsInvestigation
|
Wait, no. In that stack trace @anacrolix, can you post the complete goroutine dump from a failure? |
bcmills
added
the
WaitingForInfo
|
Thank you for looking into this @bcmills. That's actually the only thing it outputs when it crashes. Here it is with GOTRACEBACK=system |
|
We actually have a similar issue on Intel Macs (go1.20.3, go1.20.5): panics while connecting to VPN using Cisco AnyConnect. It seems, at some point What's interesting is that the left index is always the same Can this be a trampoline messing with memory layout? or some kind of alignment issue? UPD: Apple Silicon Macs panic as well but with arbitrary left index. UPD2: Disabling HTTP KeepAlives "fixes" the issue. |
bcmills
removed
the
WaitingForInfo
|
Huh. At the very least Even so, we should narrow down whether it is a Go bug or a macOS bug.
|
bcmills
added
the
compiler/runtime
|
Personally I don't think that the Go standard library should have to double-check that the It should be possible to use dtruss to verify that |
I agree with that in principle, but I also think that if we have reason to believe that a particular system call may be broken, it benefits our users to make the problem easier to diagnose — and the run-time cost of an (I don't think we need to try to rush a check into 1.21 or backport it to older releases, but I do think we should consider it for 1.22 so that if this happens for other users they will be able to figure out what's going on more easily.) |
I tried, but no luck so far. When I run go reproducer under dtruss I can't see any
Will try next week when I get access to my Intel Mac. Disabling ipv6 also "fixes" this issue. |
|
I can run publicip -6 with dtruss and Mullvad if it helps |
I'm inclined to suspect I also wouldn't be terribly surprised if the reproducer requires multiple threads. If there is a synchronization bug in the VPN layer, the fact that the Go runtime may make its |
|
I couldn't determine much from the output. Without a VPN I see: write(0x6, "\347\017\001\0", 0x2D) = 45 0 and with I see: write(0x6, "\0", 0x2D) = 0 Err#-2 AFAICT, this is the UDP socket it's sending DNS queries from. Let me know if the full dtruss output is useful. |
|
Thanks. Both of those system calls look OK (although error -2 is weird). What we suspect is a case where the system call returns a number that is larger than the third argument. If there are no such calls in dtruss then it could conceivably be a C library problem somehow, as suggested earlier. How is the VPN implemented? Does it somehow intercept calls to the C |
Just tried the go reproducer on
|
|
The VPN is Mullvad. I only know that it's using wireguard underneath. |
|
I also get the same panic when using the same program under wine64 on Darwin. I'm inclined to think this is a Go resolver issue from the original stack trace I provided, and not Darwin specific. |
|
@anacrolix, if this is a kernel (or perhaps even a libc) bug, wouldn't wine64 on Darwin be subject to that bug too? Wine “translates Windows API calls into POSIX calls on-the-fly”, so presumably it would end up in the same POSIX |
|
Sorry I forgot to follow up, I tested on Windows directly and there was no issue as far as I can recall. |
|
Can't reproduce this bug on macOS Sonoma Beta 7 release, probably Apple fixed it. |
|
I'm also on Sonoma and can't reproduce it there. Yes, my original app, and the |
Apple "un-fixed" it in Sonoma Stable :( Most likely related to Can't reproduce panic while running go repro script together with |
|
I'll try again with Sonoma stable and report back. |
|
Yes, it crashes again on Sonoma stable ( |
|
I'm having the same issue, running This happens when my device is cut off from the network with firewall rules, but DNS IPs are whitelisted and I try to hit a host. Without going into too much detail I'm setting up some pfctl rules, starting with This has been working fine for a while, just started to encounter this with either an updated Go version or updated Mac version I think? I also see the exact same error as above: |
|
Change https://go.dev/cl/577955 mentions this issue: |
For #61060 Change-Id: I13cd73b4062cb7bd248d2a4afae06dfa29ac0203 Reviewed-on: https://go-review.googlesource.com/c/go/+/577955 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Commit-Queue: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
|
I've improved the panic message so that it clearly indicates the problem. I don't think there is anything else to do here. If the |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
It occurs with 1.21, 1.20, and earlier version too (untested)
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Probably try to resolve an IP
What did you expect to see?
It resolve
What did you see instead?
The text was updated successfully, but these errors were encountered: