[Release/1.6] vendor: golang.org/x/net v0.17.0#9387
[Release/1.6] vendor: golang.org/x/net v0.17.0#9387estesp merged 3 commits intocontainerd:release/1.6from
Conversation
full diff: golang/sys@v0.10.0...v0.13.0 Signed-off-by: Sebastiaan van Stijn <[email protected]> (cherry picked from commit ff602c2) Signed-off-by: Kern Walster <[email protected]>
full diff: golang/text@v0.11.0...v0.13.0 Signed-off-by: Sebastiaan van Stijn <[email protected]> (cherry picked from commit c365254) Signed-off-by: Kern Walster <[email protected]>
full diff: golang/text@v0.13.0...v0.17.0 This fixes the same CVE as go1.21.3 and go1.20.10; - net/http: rapid stream resets can cause excessive work A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded to the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit. New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 v0.17.0, for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function. This is CVE-2023-39325 and Go issue https://go.dev/issue/63417. This is also tracked by CVE-2023-44487. Signed-off-by: Sebastiaan van Stijn <[email protected]> (cherry picked from commit f7c9e99) Signed-off-by: Kern Walster <[email protected]>
|
Hi @Kern--. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
I tried to mimic #9276. I did the cherry pick for the commit context, but checked out everything other than the go.mod. I then fixed the conflicts and reran |
Thanks! Yes, preserving the commit message for these can be useful to provide context 👍 ❤️ |
5 participants
vendor: golang.org/x/sys v0.13.0
full diff: golang/sys@v0.10.0...v0.13.0
vendor: golang.org/x/text v0.13.0
full diff: golang/text@v0.11.0...v0.13.0
vendor: golang.org/x/net v0.17.0
full diff: golang/net@v0.13.0...v0.17.0
This fixes the same CVE as go1.21.3 and go1.20.10;
net/http: rapid stream resets can cause excessive work
A malicious HTTP/2 client which rapidly creates requests and
immediately resets them can cause excessive server resource consumption.
While the total number of requests is bounded to the
http2.Server.MaxConcurrentStreams setting, resetting an in-progress
request allows the attacker to create a new request while the existing
one is still executing.
HTTP/2 servers now bound the number of simultaneously executing
handler goroutines to the stream concurrency limit. New requests
arriving when at the limit (which can only happen after the client
has reset an existing, in-flight request) will be queued until a
handler exits. If the request queue grows too large, the server
will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 v0.17.0,
for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests)
per HTTP/2 connection. This value may be adjusted using the
golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams
setting and the ConfigureServer function.
This is GHSA-4374-p667-p6c8 and Go issue https://go.dev/issue/63417.
This is also tracked by GHSA-qppj-fm5r-hxr3.