Pass buffer.End to AdvanceTo #27586
Merged
Pass buffer.End to AdvanceTo #27586
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
jkotalik
approved these changes
Nov 6, 2020
|
Something we'd consider for a patch? |
This was reported in both 3.1 and 5.0, but I don't currently recommend backporting the fix because it won't help the operation succeed, it will only help fail with a better error message. We'll see if we get more reports about this. |
|
Hello @Tratcher! Because this pull request has the Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 60 minutes, a condition that will be fulfilled in about 28 minutes. No worries though, I will be back when the time is right! 😉 p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
halter73
approved these changes
Nov 6, 2020
|
backport? |
@davidfowl is it worth it? |
ghost
merged commit
|
OK, lets wait |
vseanreesermsft
pushed a commit
to vseanreesermsft/aspnetcore
that referenced
this pull request
Mar 8, 2022
…in ASP.NET Core via FormPipeReader # [3.1] MSRC 69432 - ASP.NET Core - Denial of service in ASP.NET Core via FormPipeReader Fixes a bug in FormPipeReader where data without a delimiter will be buffered indefinitely, beyond configured limits. ## Description When chunked data without a delimiter is sent to FormPipeReader, FormPipeReader will read the entire stream of data, starting from the beginning each time, without honoring configured length limits. This is because, after each read, it checks if `SequenceReader.Consumed` is greater than the configured limit, but `SequenceReader.Consumed` is 0 when no delimiter was found. Therefore the check against the length limit is never honored, and we continue to read data indefinitely, starting from the beginning of the stream each time. Also brings in the changes from dotnet#27586 ## Customer Impact Potential Denial-Of-Service attack on services using FormPipeReader ## Regression? - [ ] Yes - [ x ] No [If yes, specify the version the behavior has regressed from] ## Risk - [ ] High - [ x ] Medium - [ ] Low The fix is a one-liner, and tests confirm a significant positive improvement on perf. There could be orthogonal issues that we've missed ## Verification - [ x ] Manual (required) - [ x ] Automated ## Packaging changes reviewed? - [ x ] Yes - [ ] No - [ ] N/A ---- ## When servicing release/2.1 - [ ] Make necessary changes in eng/PatchConfig.props FormPipeReader
vseanreesermsft
pushed a commit
to vseanreesermsft/aspnetcore
that referenced
this pull request
Mar 8, 2022
…in ASP.NET Core via FormPipeReader # [5.0] MSRC 69432 - ASP.NET Core - Denial of service in ASP.NET Core via FormPipeReader Fixes a bug in FormPipeReader where data without a delimiter will be buffered indefinitely, beyond configured limits. ## Description When chunked data without a delimiter is sent to FormPipeReader, FormPipeReader will read the entire stream of data, starting from the beginning each time, without honoring configured length limits. This is because, after each read, it checks if `SequenceReader.Consumed` is greater than the configured limit, but `SequenceReader.Consumed` is 0 when no delimiter was found. Therefore the check against the length limit is never honored, and we continue to read data indefinitely, starting from the beginning of the stream each time. Also brings in the changes from dotnet#27586 ## Customer Impact Potential Denial-Of-Service attack on services using FormPipeReader ## Regression? - [ ] Yes - [ x ] No [If yes, specify the version the behavior has regressed from] ## Risk - [ ] High - [ x ] Medium - [ ] Low The fix is a one-liner, and tests confirm a significant positive improvement on perf. There could be orthogonal issues that we've missed ## Verification - [ x ] Manual (required) - [ x ] Automated ## Packaging changes reviewed? - [ x ] Yes - [ ] No - [ ] N/A ---- ## When servicing release/2.1 - [ ] Make necessary changes in eng/PatchConfig.props FormPipeReader
amcasey
added
area-networking
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #27585 The FormPipeReader calls AdvanceTo in two places. One is called each time through the loop and the other when an exception is thrown. In this example there was a long field that exceeded the limit, but not until after the first buffer was consumed and AdvanceTo had been called. When the exception was thrown AdvanceTo was called again, but only with Buffer.Start, causing examined to go back to Start and trigger an exception in the pipe reader. The fix is for AdvanceTo to pass both Start and End.