-
-
Notifications
You must be signed in to change notification settings - Fork 270
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
Fix for a fuzzer-discovered integer underflow of the flow control window size #692
Conversation
self.inner.streams.set_target_connection_window_size(size); | ||
let _res = self.inner.streams.set_target_connection_window_size(size); | ||
// TODO: proper error handling | ||
debug_assert!(_res.is_ok()); |
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.
There are some debug left around here and in other files. Are these on purpose?
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.
Yes. Whenever it was obvious on how to handle a potential overflow, I did. However, many of the call sites do not have a Result
return type, so it is not easy to propagate the Error. I assume that those functions should not be able not fail. I did not want to incur additional overhead in release builds, so I stuck with debug_assert!
and left the TODO
comment. For those TODOs someone with more experience with the code should check whether they are fine to be left as debug_assert!
, whether they should be checked with assert!
or whether error propagation is needed.
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.
FYI: I did more fuzzing runs with this patch and none of the debug_assert!
are triggered, so that gives some assurance that the they are indeed not reachable. So I think we could remove the todo comments, but I would leave the debug_assert!
as is.
ead98f1
to
09d4849
Compare
…dow size Removed the SubAssign, etc. syntactic sugar functions and switched to return Result on over/underflow Whenever possible, switched to returning a library GoAway protocol error. Otherwise we check for over/underflow only with `debug_assert!`, assuming that those code paths do not over/underflow. Signed-off-by: Michael Rodler <mrodler@amazon.de> Co-Authored-By: f0rki <m@mrodler.eu> Reviewed-by: Daniele Ahmed <ahmeddan@amazon.de>
09d4849
to
eb10db0
Compare
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
@f0rki is it ready for review? |
looks good to me @82marbag @seanmonstar |
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.
Excellent work, thank you!
…dow size (hyperium#692) Removed the SubAssign, etc. syntactic sugar functions and switched to return Result on over/underflow Whenever possible, switched to returning a library GoAway protocol error. Otherwise we check for over/underflow only with `debug_assert!`, assuming that those code paths do not over/underflow. Signed-off-by: Michael Rodler <mrodler@amazon.de> Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de> Co-authored-by: Michael Rodler <mrodler@amazon.de> Co-authored-by: Daniele Ahmed <ahmeddan@amazon.de>
…dow size (hyperium#692) Removed the SubAssign, etc. syntactic sugar functions and switched to return Result on over/underflow Whenever possible, switched to returning a library GoAway protocol error. Otherwise we check for over/underflow only with `debug_assert!`, assuming that those code paths do not over/underflow. Signed-off-by: Michael Rodler <mrodler@amazon.de> Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de> Co-authored-by: Michael Rodler <mrodler@amazon.de> Co-authored-by: Daniele Ahmed <ahmeddan@amazon.de>
…dow size (hyperium#692) Removed the SubAssign, etc. syntactic sugar functions and switched to return Result on over/underflow Whenever possible, switched to returning a library GoAway protocol error. Otherwise we check for over/underflow only with `debug_assert!`, assuming that those code paths do not over/underflow. Signed-off-by: Michael Rodler <mrodler@amazon.de> Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de> Co-authored-by: Michael Rodler <mrodler@amazon.de> Co-authored-by: Daniele Ahmed <ahmeddan@amazon.de> Signed-off-by: Sven Pfennig <s.pfennig@reply.de>
Fuzzing discovered a integer underflow in the flow control handling that can be triggered by a certain sequence of frames. In release builds this would lead to wrap-around of the negative window. This seems incorrect to me. I did not find anything definitive in the http2 spec.
Removed the SubAssign, etc. syntactic sugar functions and switched to return Result on over/underflow
Whenever possible, switched to returning a library GoAway protocol error. Otherwise we check for over/underflow only with
debug_assert!
, assuming that those code paths do not over/underflow. In this case I leftTODO:
comments.