Fix: Do not try to call deframer on junk data #2575
Merged
Conversation
This file contains hidden or 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
After receiving close notify, the TLS stream ends. The receive buffer can contain additional junk data received past close notify record, which obviously cannot be interpreted anymore. However, `UnbufferedConnectionCommon::process_tls_records_common()` tried to interpret this junk data. Add a check for `has_received_close_notify` to prevent calling the deframer on junk data. Also update the test to test also with a longer junk data (original junk data didn't trigger the bug).
Contributor
Author
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2575 +/- ##
=======================================
Coverage 95.28% 95.28%
=======================================
Files 97 97
Lines 21562 21566 +4
=======================================
+ Hits 20545 20549 +4
Misses 1017 1017 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ctz
approved these changes
Jul 25, 2025
Member
There was a problem hiding this comment.
Thanks!
For other reviewers: the equivalent buffered behaviour is here
Lines 712 to 714 in 76cc2ca
test_read_tls_artificial_eof_after_close_notify. So this difference is another thing potentially addressed by #1723.
The idea of handling alerts in the state machine I think is a good one, but beware that the state machine operates on a sequence of whole TLS messages, so it has a limited effect on layers above that (and whether to read data at all is several layers above that). The other thing to note here is that every state in every state machine would need to handle alerts in exactly the same way; that commonality is why it doesn't currently happen in this way. But that is nothing some additional layering (eg, make State::handle concrete and handle alerts, before passing off to the state-specific code)
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
cpu
approved these changes
Jul 25, 2025
Contributor
Author
|
@ctz & @cpu Thanks for the review and merging the fix. I just have one question: what is the strategy to get fixes to |
Member
Right now I kicked the process off over here: #2576 |
Member
The fix is now available on crates.io as part of Rustls v0.23.30. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
After receiving close notify, the TLS stream ends. The receive buffer can contain additional junk data received past close notify record, which obviously cannot be interpreted anymore.
However,
UnbufferedConnectionCommon::process_tls_records_common()tried to interpret this junk data.Add a check for
has_received_close_notifyto prevent calling the deframer on junk data. Also update the test to test also with a longer junk data (original junk data didn't trigger the bug).