Fix infinite loop during reverse iteration due to corrupted stream#14423
Merged
sundb merged 4 commits intoredis:unstablefrom Oct 15, 2025
Merged
Fix infinite loop during reverse iteration due to corrupted stream#14423sundb merged 4 commits intoredis:unstablefrom
sundb merged 4 commits intoredis:unstablefrom
Conversation
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR fixes an infinite loop bug that occurs during reverse iteration of Redis streams when the lp_count field in a stream entry is corrupted. The fix adds a boundary check to prevent the iterator from moving beyond the current entry during reverse iteration.
- Adds boundary validation to detect when reverse iteration steps beyond entry limits
- Includes test case to verify the fix prevents infinite loops with corrupted stream data
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/t_stream.c | Adds boundary tracking and assertion to prevent infinite loops during reverse stream iteration |
| tests/integration/corrupt-dump.tcl | Adds test case with corrupted stream data to verify the infinite loop fix |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <[email protected]>
oranagra
approved these changes
Oct 12, 2025
sundb
added a commit
that referenced
this pull request
Jan 5, 2026
…f corrupted stream (#14472) Follow #14423 In #14423, I thought the last lpNext operation of the iterator occurred at the end of streamIteratorGetID. However, I overlooked the fact that after calling `streamIteratorGetID()`, we might still use `streamIteratorGetField()` to continue moving within the current entry. This means that during reverse iteration, the iterator could move back to a previous entry position. To fix this, in this PR I record the current position at the beginning of streamIteratorGetID(). When we enter it again next time, we ensure that the entry position does not exceed the previous one, that is, during forward iteration the entry must be greater than the last entry position, and during reverse iteration it must be smaller than the last entry position. Note that the fix for #14423 has been replaced by this fix.
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
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.
When the
lp_countof a stream entry is incorrect, and we are performing a reverse iteration, we can normally move backward bylp_countto locate the previous entry.However, if
lp_countis wrong, during forward iteration, after obtaining the flag, ID, and other fields, we may step beyond the current entry into the start position of the next entry(where we came from), which could cause an infinite loop.