-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
x/net/route: ParseRIB panics on message from Darwin #70528
Comments
Thanks, I will take a look at this on the weekend. |
@raggi do you have the bytes array so that I can write up a test for this? |
@hurricanehrndz I'm working on getting that, in the meantime this should be sufficient defense: https://github.com/golang/net/compare/master...raggi:raggi/darwin-rib-parse?expand=1 |
Updates #14201 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>
@raggi yeah that looks good. |
Updates #14201 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>
I was able to gather a panicking RIB from a real darwin amd64 machine using a coredump: data := []byte{
0x84, 0x00, 0x05, 0x04, 0x01, 0x00, 0x00, 0x00, 0x03, 0x08, 0x00, 0x01, 0x15, 0x00, 0x00, 0x00,
0x1B, 0x01, 0x00, 0x00, 0xF5, 0x5A, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x02, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,
0x14, 0x12, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
}
_, _ = route.ParseRIB(route.RIBTypeRoute, data)
raggi's patch does seem to fix the panic in this case. It might be related to a recent MacOS update, since the RIB above was gathered from a 15.1 machine (released Oct 28th). |
I was hoping we'd catch an example input quickly, but the reporter had rebooted their machine and it is no longer exhibiting the behavior. As such this code may be sticking around quite a bit longer and we might encounter other errors, so include the panic in the log entry. Updates #14201 Updates #14202 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>
Zero-length sockaddrs were observed in RIBs within golang/go#70528. These records are to be skipped, and an invariant for later slice manipulation is to be enforced by a defensive check in parseAddr. Fixes golang/go#70528
Zero-length sockaddrs were observed in RIBs within golang/go#70528. These records are to be skipped, and an invariant for later slice manipulation is to be enforced by a defensive check in parseAddr. Fixes golang/go#70528
agreed, 15.1 changes are the likely cause. |
Change https://go.dev/cl/631475 mentions this issue: |
I was hoping we'd catch an example input quickly, but the reporter had rebooted their machine and it is no longer exhibiting the behavior. As such this code may be sticking around quite a bit longer and we might encounter other errors, so include the panic in the log entry. Updates #14201 Updates #14202 Updates golang/go#70528 Signed-off-by: James Tucker <james@tailscale.com>
Zero-length sockaddrs were observed in RIBs within golang/go#70528. These records are to be skipped, and an invariant for later slice manipulation is to be enforced by a defensive check in parseAddr. Fixes golang/go#70528
Zero-length sockaddrs were observed in RIBs within golang/go#70528. These records are to be skipped, and an invariant for later slice manipulation is to be enforced by a defensive check in parseAddr. Fixes golang/go#70528
I know this issue is closed, but I wanted to chime in that I can reproduce this panic (without golang/net@e9cd716) on darwin on macOS 14.7.1, as opposed to only 15.1 like previously suggested. |
Change https://go.dev/cl/646555 mentions this issue: |
sa_len of 0 should be valid, for Chapter 18 of UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking API, states: The socket address structures are variable-length, but this code assumes that each has an sa_len field specifying its length. There are two complications that must be handled. First, the two masks, the network mask and the cloning mask, can be returned in a socket address structure with an sa_len of 0, but this really occupies the size of an unsigned long. (Chapter 19 of TCPv2 discusses the cloning feature of the 4.4BSD routing table). This value represents a mask of all zero bits, which we printed as 0.0.0.0 for the network mask of the default route in our earlier example. There are other references in the book which also state sa_len of 0 is valid. Fixes golang/go#70528 Change-Id: I9205a674f9cdf8091b1cc8b8a56609cd1cf4c670 GitHub-Last-Rev: df63086 GitHub-Pull-Request: #230 Reviewed-on: https://go-review.googlesource.com/c/net/+/646555 Auto-Submit: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Change https://go.dev/cl/646676 mentions this issue: |
This applies CL 646555 from the net repository to this copy. For #70528 Change-Id: Ib7e23accfa3f278392e7bdca6f8544b8f1395e7e Reviewed-on: https://go-review.googlesource.com/c/go/+/646676 Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> TryBot-Bypass: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Change https://go.dev/cl/646975 mentions this issue: |
For #70528. Change-Id: I0db75cb998aeb299676384fe59bf241db18ebc5c Reviewed-on: https://go-review.googlesource.com/c/go/+/646975 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Go version
go1.23.3 & golang.org/x/net@v0.30.0
Output of
go env
in your module/workspace:What did you do?
Seen from tailscale client, usage at https://github.com/tailscale/tailscale/blob/8e5cfbe4ab11713e383b3ff0d978f116320de2a3/net/netmon/netmon_darwin.go#L59
What did you see happen?
What did you expect to see?
No panic.
Related issue: #44740
Related change: hurricanehrndz/golang-net@61924c1
The text was updated successfully, but these errors were encountered: