-
Notifications
You must be signed in to change notification settings - Fork 61
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 S2N blocked issue #589
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #589 +/- ##
==========================================
- Coverage 79.94% 79.90% -0.05%
==========================================
Files 27 27
Lines 5845 5848 +3
==========================================
Hits 4673 4673
- Misses 1172 1175 +3
☔ View full report in Codecov by Sentry. |
} else { | ||
AWS_LOGF_ERROR( | ||
AWS_LS_IO_TLS, | ||
"id=%p: Error decrypting message. Unexpected type of output 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.
ask henso about this case
if this is the right way to handle it, or if he intended something else to happen
Co-authored-by: Michael Graeb <[email protected]>
Description of changes:
Fixes the use of
s2n_recv
. The blocked value is only guaranteed to be meaningful if s2n_error_get_type(s2n_errno) == S2N_ERR_T_BLOCKED. If the error type is something else, the blocked value is meaningless and cannot be relied on for any logic. Currently, the return values are all treated the same and if any fatal error occurs we can end up in an endless loop because blocked value can be garbage.Example of how to integrate properly here. Note that you don't really even need to read the blocked value at all. It's simply there to tell you what type of blocking happened.
Another issue that can occur when multi-record mode is enabled is S2N will fill up the provided buffer entirely and the blocked status will have a "junk" value. Since the return value is >0 and s2n_error_get_type(s2n_errno) is not S2N_ERR_T_BLOCKED. The blocked value does end up with S2N_BLOCKED_ON_READ so, luckily, the loop exits. But as
there's no event to wake it back up because it wasn't actually blocked on a socket operation and we will end up never reading the rest of the data.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.