The bpf VM did not correctly check the bounds of LoadMemShift
instructions, as it used a size of 0 instead of the correct 1.
A LoadMemShift instruction 1 past the end of the input resulted in a
runtime panic:
panic(0x5c1d40, 0x7cec00)
/usr/local/go/src/runtime/panic.go:522 +0x1b5
golang.org/x/net/bpf.loadMemShift(...)
/home/afabre/go/pkg/mod/golang.org/x/net@v0.0.0-20190603091049-60506f45cf65/bpf/vm_instructions.go:137
golang.org/x/net/bpf.(*VM).Run(0xc00000ec40, 0xc0000173c8, 0x2, 0x8, 0x2, 0xc0000173c8, 0x0)
/home/afabre/go/pkg/mod/golang.org/x/net@v0.0.0-20190603091049-60506f45cf65/bpf/vm.go:131 +0xb0a
Fix this, and rework the out of bounds tests for load instructions to:
* Use an offset one past the end of the input, to catch this
* Use a filter that returns 1, to catch cases were the out of bounds
load does not cause a panic, but does not cause the VM to return 0.
Change-Id: I1e68886915207a34f59765805f907f36dc031f70
Reviewed-on: https://go-review.googlesource.com/c/net/+/180979
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Use the AF_UNSPEC, AF_INET, AF_INET6 and SOCK_RAW constants from
golang.org/x/sys instead of locally deriving them from the C headers (or
hard coding them in the case of Windows).
Change-Id: I37fe61d0435b6c615cd767eef38380db4b4af7b1
Reviewed-on: https://go-review.googlesource.com/c/net/+/53310
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
nextStreamID was used as a means to determine if the connection was
being reused. Multiple requests can see a new connection because the
nextStreamID is updated after a ClientTrace reports it is being reused.
Updates golang/go#31982
Change-Id: Iaa4b62b217f015423cddb99fd86de75a352f8320
Reviewed-on: https://go-review.googlesource.com/c/net/+/176720
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit newly introduces a type for configuring a parser
called ParseOption, and implements two functions depending on it.
Along with that, this introduces ParseOptionEnableScripting to
enable setting of the scripting flag.
Fixesgolang/go#16318
Change-Id: Ie7fd7d8ce286e22e7f57182fc2ce353bce578db6
Reviewed-on: https://go-review.googlesource.com/c/net/+/174157
Reviewed-by: Nigel Tao <nigeltao@golang.org>
EffectiveTLDPlusOne hands it argument to PublicSuffix which produces
output for all its arguments, even for non-domain names like ".com.au"
and does not report an error.
This CL captures this type of malformed input to EffectiveTLDPlusOne
and returns an error if any label in the domain name is empty (or the
domain is fully qualified).
This is still not a proper input validation e.g. IP addresses can
still be fed into EffectiveTLDPlusOne without error.
Fixesgolang/go#30652
Change-Id: I12b0945bc3c7e5d192a71c5488361a60a48454b1
Reviewed-on: https://go-review.googlesource.com/c/net/+/172537
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the spec 12.2.6.4.5, the "in head noscript" insertion mode is defined.
However, this package and its parser doesn't have the insertion mode,
because the scripting=false case is not considered currently.
This commit adds a test and a support for the "in head noscript"
insertion mode. This change has no effect on the actual behavior.
Updates golang/go#16318
Change-Id: I9314c3342bea27fa2acf2fa7d980a127ee0fbf91
Reviewed-on: https://go-review.googlesource.com/c/net/+/172557
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Pre-declared trailers are written after a server's request handler
returns, in which case the trailer header frame is also responsible
for closing the stream. However, if the server handler does not
define a trailer header value before returning, the headers are empty
and no header frame is written. In this case, the stream would simply
hang.
This change fixes this by closing the stream if there are no header
values but endStream is true. Some other options to consider:
1. Reset the stream with an error; the user didn't define a trailer value
as they said they would. From my brief reading of the http/2 RFC,
this isn't actually required.
2. Send an explicitly empty header value.
Change-Id: I07e01250df60ac33fa6d34beb81ec2fa7e43c146
GitHub-Last-Rev: dfc532d785
GitHub-Pull-Request: golang/net#31
Reviewed-on: https://go-review.googlesource.com/c/net/+/161958
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing implementation behaves differently to all major browsers, for the instance where a self-closing element of an unknown tag type is the child of another element of an unknown tag type. The issue appears to be that nested tags of an differing unknown types will all have an atom value of 0 and `inBodyEndTagOther` will incorrectly match them to one another.
Fixesgolang/go#30961
Change-Id: I62b0aa49c027c8432df7d077ffba135201b3b786
GitHub-Last-Rev: fb25181f9a
GitHub-Pull-Request: golang/net#37
Reviewed-on: https://go-review.googlesource.com/c/net/+/168638
Reviewed-by: Nigel Tao <nigeltao@golang.org>
On FreeBSD 11.3 or 12 kernel running COMPAT_FREEBSD32, it looks like the
system call recvmsg always returns an incorrect length for the
out-of-band data. This change adjusts the length when it looks incorrect
and the running kernel is FreeBSD 11.3 or above.
Fixesgolang/go#30899.
Change-Id: Ia58d8b4bd4caf3783d2e38161ee4afd1a64ca522
Reviewed-on: https://go-review.googlesource.com/c/net/+/168297
Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On FreeBSD 12 kernel running COMPAT_FREEBSD32, it looks like the system
call recvmsg always returns an incorrect length for the out-of-band
data. This change adjusts the length when it looks incorrect.
Fixesgolang/go#30899.
Change-Id: Ibb0cbcf9b1f5f959279c20395916d47bd75d289c
Reviewed-on: https://go-review.googlesource.com/c/net/+/168077
Reviewed-by: Ian Lance Taylor <iant@golang.org>
