-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
test: fix use after free in oauth_integration_test #14103
test: fix use after free in oauth_integration_test #14103
Conversation
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Signed-off-by: Antonio Vicente <avd@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks for debugging and fixing.
@@ -91,8 +91,6 @@ TEST_F(OauthIntegrationTest, UnauthenticatedFlow) { | |||
{":authority", "authority"}}; | |||
auto encoder_decoder = codec_client_->startRequest(headers); | |||
|
|||
Buffer::OwnedImpl buffer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually wonder if responding before the request is complete (since this is effectively what is tested now) is going to break some clients who don't handle this well? Unrelated to this test fix but maybe something to think about in the future. cc @rgs1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we add the above as a note?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it might be worth it to document this somewhere but up to you all as whether to do it in here or a follow up, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is generic H2 behavior. The proxy does have fully request headers for the GET by the time it replies. I'll make a note to try to look at the more general issue in test frameworks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I know it's correct/generic behavior, I was just suggesting that I can envision some clients not dealing with this well so we should keep that in mind for future support queries.
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes envoyproxy#12960 Signed-off-by: Antonio Vicente <avd@google.com>
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes envoyproxy#12960 Signed-off-by: Antonio Vicente <avd@google.com> Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes envoyproxy#12960 Signed-off-by: Antonio Vicente <avd@google.com> Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes #12960 Signed-off-by: Antonio Vicente <avd@google.com> Signed-off-by: Christoph Pakulski <christoph@tetrate.io> Co-authored-by: antonio <avd@google.com>
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes envoyproxy#12960 Signed-off-by: Antonio Vicente <avd@google.com>
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest. Fixes envoyproxy#12960 Signed-off-by: Antonio Vicente <avd@google.com> Signed-off-by: Qin Qin <qqin@google.com>
Backported to rel 1.16. Releases 1.13-1.15 do not have oauth_integration_test and are not affected. |
Commit Message:
test: fix use after free in oauth_integration_test
The client request stream can be deleted under the call stack of Envoy::IntegrationCodecClient::startRequest if the proxy replies quickly enough. Attempts to send an end stream on that request result in use-after-free on the client stream in cases where the client processed the full reply inside startRequest.
Additional Description:
Risk Level: n/a test-only
Testing: n/a
Docs Changes: n/a
Release Notes: n/a
Fixes #12960