-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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.
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
net/http: No graceful closing of the connection after sending GOAWAY #55846
Comments
Upgrading golang.org/x/net in k8s raises issues |
Not sure this fix will cause CVE-2022-27664 to open, can you give me more details? |
Related to this #32112 |
This is a bug in the HTTP/2 server's handling of RST_STREAM frames: After sending a GOAWAY frame, the server should ignore frames for streams greater than the last stream identifier sent in the GOAWAY frame. We do this for HEADERS and DATA frames, but not for RST_STREAM. The HTTP/2 client is sending a RST_STREAM for the aborted streams (which it doesn't need to do, but is allowed to do), and the server is treating this as a protocol violation. This wasn't apparent previous to https://go.dev/cl/428735, because the PROTOCOL_ERROR state was silently discarded. I should have a fix shortly. |
Change https://go.dev/cl/434909 mentions this issue: |
I tested it with no more problems.
|
does the standard library also need to be repaired |
@neild if you move the logic to skip frames based on the stream id to the @@ -1459,6 +1460,14 @@ func (sc *serverConn) processFrame(f Frame) error {
sc.sawFirstSettings = true
}
+ if sc.inGoAway && f.Header().StreamID > sc.maxClientStreamID {
+ sc.vlogf("http2: server ignoring frame: %v", f.Header())
+ // Section 6.8: After sending a GOAWAY frame, the sender
+ // can discard frames for streams initiated by the
+ // receiver with identifiers higher than the identified
+ // last stream.
+ return nil
+ }
switch f := f.(type) |
nevermind, I didn't see you already had a patch with the fix https://go.dev/cl/434909 |
After sending a GOAWAY with NO_ERROR, we should discard all frames for streams with larger identifiers than the last stream identifier in the GOAWAY frame. We weren't discarding RST_STREAM frames, which could cause us to incorrectly detect a protocol error when handling a RST_STREAM for a discarded stream. Hoist post-GOAWAY frame discarding higher in the loop rather than handling it on a per-frame-type basis. We are also supposed to count discarded DATA frames against connection-level flow control, possibly sending WINDOW_UPDATE messages to return the flow control. We weren't doing this; this is now fixed. Fixes golang/go#55846 Change-Id: I7603a529c00b8637e648eee9cc4608fb5fa5199b Reviewed-on: https://go-review.googlesource.com/c/net/+/434909 Reviewed-by: Heschi Kreinick <[email protected]> Run-TryBot: Damien Neil <[email protected]> Auto-Submit: Damien Neil <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: LI ZHEN <[email protected]> Reviewed-by: Antonio Ojea <[email protected]>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
https://pkg.go.dev/vuln/GO-2022-0969
https://go.dev/cl/428735
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go get -u golang.org/x/net
What did you expect to see?
Existing streams are processed normally after sending GOAWAY and no new streams are accepted
What did you see instead?
Existing stream is incorrectly terminated
Related to this #54658
@neild Can you help me look at it?
This will alleviate
Question was introduced by https://go.dev/cl/428735
The text was updated successfully, but these errors were encountered: