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

x/net/route: ParseRIB still panics on macOS #71557

Closed
bradfitz opened this issue Feb 4, 2025 · 8 comments
Closed

x/net/route: ParseRIB still panics on macOS #71557

bradfitz opened this issue Feb 4, 2025 · 8 comments

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Feb 4, 2025 •
edited
Loading

go version go1.23.5 darwin/arm64

The #70528 fun continues... we now see panics in x/net/route ParseRIB even at v0.34.0:

2025-02-03T08:09:41Z	panic: runtime error: slice bounds out of range [8:2]
2025-02-03T08:09:41Z	
2025-02-03T08:09:41Z	goroutine 93 [running]:
2025-02-03T08:09:41Z	golang.org/x/net/route.parseInetAddr(0x14000428dc8?, {0x140002e3290, 0x14000d0e700?, 0x788})
2025-02-03T08:09:41Z	golang.org/x/net@v0.34.0/route/address.go:203 +0x290
2025-02-03T08:09:41Z	golang.org/x/net/route.parseAddrs(0x15, 0x103810768, {0x140002e3274, 0x34, 0x7a4})
2025-02-03T08:09:41Z	golang.org/x/net@v0.34.0/route/address.go:411 +0xfc
2025-02-03T08:09:41Z	golang.org/x/net/route.(*wireFormat).parseRouteMessage(0x1400000e030, 0x14000100008?, {0x140002e3218, 0x90, 0x800})
2025-02-03T08:09:41Z	golang.org/x/net@v0.34.0/route/route_classic.go:70 +0x2b8
2025-02-03T08:09:41Z	golang.org/x/net/route.ParseRIB(0x1, {0x140002e3218?, 0x14000d0e600?, 0x800?})
2025-02-03T08:09:41Z	golang.org/x/net@v0.34.0/route/message.go:55 +0x194
2025-02-03T08:09:41Z	tailscale.com/net/netmon.(*darwinRouteMon).Receive(0x140002e3208)
2025-02-03T08:09:41Z	tailscale.com@v1.80.0/net/netmon/netmon_darwin.go:59 +0x60
2025-02-03T08:09:41Z	tailscale.com/net/netmon.(*Monitor).pump(0x140002c2000)
2025-02-03T08:09:41Z	tailscale.com@v1.80.0/net/netmon/netmon.go:346 +0x78
2025-02-03T08:09:41Z	created by tailscale.com/net/netmon.(*Monitor).Start in goroutine 17
2025-02-03T08:09:41Z	tailscale.com@v1.80.0/net/netmon/netmon.go:265 +0x1b8

/cc @raggi @hurricanehrndz
@hurricanehrndz
Copy link

I was in the process of fixing other issues in the pkg with address parsing, can you please do a recover and produce byte array so I can add it to the tests cases, otherwise I will submit a fix this morning.

@hurricanehrndz
Copy link

Also length of 2 seems odd, since the only address that should have variable lengths are netmasks and IPv4 address typically are valid if the have a length of one of the following 0, 5, 6, 7, 8

Unix Networking Programming Volume 1

. The sa_family
member is undefined, but the mask socket address structures do contain an sa_len
of 0, 5, 6, 7, or 8

Which obviously means there is at least 2 bugs in the package right now.

@hurricanehrndz
Copy link

Obviously this is an ipv6 address we are working with.

@hurricanehrndz
Copy link

hurricanehrndz commented Feb 4, 2025 •
edited
Loading

I believe I was able to replicate the issue

Image

In the image above 02 1e 00 00 should be parsed as ::

hurricanehrndz added a commit to hurricanehrndz/golang-net that referenced this issue Feb 4, 2025
@hurricanehrndz
route: treat short sockaddr lengths as unspecified

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode
90f9dd9 
Previously, we enforced minimum length requirements for sockaddr,
but the kernel can legitimately return shorter lengths. This change
treats any sockaddr with length less than the address offset as an
unspecified address (0.0.0.0 for IPv4 or :: for IPv6).

Fixes golang/go#71557
@hurricanehrndz hurricanehrndz mentioned this issue Feb 4, 2025
Closed
@hurricanehrndz
Copy link

With golang/net#231

Image

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/646556 mentions this issue: route: treat short sockaddr lengths as unspecified

hurricanehrndz added a commit to hurricanehrndz/golang-net that referenced this issue Feb 5, 2025
@hurricanehrndz
route: treat short sockaddr lengths as unspecified
085b4ee 
Previously, we enforced minimum length requirements for sockaddr,
but the kernel can legitimately return shorter lengths. This change
treats any sockaddr with length less than the address offset as an
unspecified address (0.0.0.0 for IPv4 or :: for IPv6).

Fixes golang/go#71557
hurricanehrndz added a commit to hurricanehrndz/golang-net that referenced this issue Feb 5, 2025
@hurricanehrndz
route: treat short sockaddr lengths as unspecified
396d8a2 
Previously, we enforced minimum length requirements for sockaddr, but
the route command can legitimately parse shorter lengths. This change
treats any sockaddr with length less than the address offset as an
unspecified address (0.0.0.0 for IPv4 or :: for IPv6), as discern by
monitoring the route command.

To replicate the issue, prior to the fix, execute the following:

First,
```console
route -n monitor
```

Next,
```console
sudo route -n add -inet6 -ifscope en11 -net :: \
    -netmask :: fe80::2d0:4cff:fe10:15d2
```

The route command that is actively monitor will print something such
as,
```console
RTM_ADD: Add Route: len 152, pid: 81198, seq 1, errno 0, ifscope 13, flags:<UP,GATEWAY,DONE,STATIC,IFSCOPE>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
:: fe80::2d0:4cff:fe10:15d2 ::

```

Prior to the fix, if you had parse the above message, PareRIB would have
returned errInvalidAddr which is clearly false.

Fixes golang/go#71557
@bradfitz
Copy link
Contributor Author

bradfitz commented Feb 5, 2025

can you please do a recover and produce byte array so I can add it to the tests cases

I can't reproduce at will on my machine. This is from crash telemetry from our users. We'd need to release a new version of our code with more recording to get the byte arrays.

@hurricanehrndz
Copy link

can you please do a recover and produce byte array so I can add it to the tests cases

I can't reproduce at will on my machine. This is from crash telemetry from our users. We'd need to release a new version of our code with more recording to get the byte arrays.

Yeah no worries I was able to reproduce it and there is a PR to fix it

bradfitz added a commit to tailscale/tailscale that referenced this issue Feb 11, 2025
@bradfitz
go.mod: bump x/* deps
Loading
Loading status checks…
595356c 
Notably, this pulls in https://go.googlesource.com/net/+/2dab271ff1b7396498746703d88fefcddcc5cec7
for golang/go#71557.

Updates #8043

Change-Id: I3637dbf27b90423dd4d54d147f12688b51f3ce36
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
@bradfitz bradfitz mentioned this issue Feb 11, 2025
Merged
bradfitz added a commit to tailscale/tailscale that referenced this issue Feb 11, 2025
@bradfitz
go.mod: bump x/* deps
Loading
Loading status checks…
6bdbefc 
Notably, this pulls in https://go.googlesource.com/net/+/2dab271ff1b7396498746703d88fefcddcc5cec7
for golang/go#71557.

Updates #8043

Change-Id: I3637dbf27b90423dd4d54d147f12688b51f3ce36
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz added a commit to tailscale/tailscale that referenced this issue Feb 11, 2025
@bradfitz
go.mod: bump x/* deps
Loading
Loading status checks…
27f8e2e 
Notably, this pulls in https://go.googlesource.com/net/+/2dab271ff1b7396498746703d88fefcddcc5cec7
for golang/go#71557.

Updates #8043

Change-Id: I3637dbf27b90423dd4d54d147f12688b51f3ce36
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

route: treat short sockaddr lengths as unspecified hurricanehrndz/golang-net
3 participants
@bradfitz @hurricanehrndz @gopherbot