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 possible memory corruption in FLUSHALL when a client watches more than one key #11854
Merged
oranagra
merged 3 commits into
redis:unstable
from
ranshid:fix-unwatchAllKeys-while-touchAllWatchedKeysInDb
Feb 28, 2023
Merged
Fix possible memory corruption in FLUSHALL when a client watches more than one key #11854
oranagra
merged 3 commits into
redis:unstable
from
ranshid:fix-unwatchAllKeys-while-touchAllWatchedKeysInDb
Feb 28, 2023
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
This can potentially lead to use-after-free when the next entry pointer held by the watched keys iterator is freed.
@oranagra still not able to reproduce so maybe I will refactor the test once I am able to. |
oranagra
changed the title
Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb
Fix possible memory corruption in FLUSHALL when a client watches more than one key
Feb 28, 2023
oranagra
reviewed
Feb 28, 2023
oranagra
approved these changes
Feb 28, 2023
oranagra
added
the
release-notes
indication that this issue needs to be mentioned in the release notes
label
Feb 28, 2023
oranagra
pushed a commit
to oranagra/redis
that referenced
this pull request
Feb 28, 2023
… than one key (redis#11854) Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb (which was unnecessary) This can potentially lead to use-after-free and memory corruption when the next entry pointer held by the watched keys iterator is freed when unwatching all keys of a specific client. found with address sanitizer, added a test which will not always fail (depending on the random dict hashing seed) problem introduced in redis#9829 (Reids 7.0) Co-authored-by: Oran Agra <oran@redislabs.com> (cherry picked from commit 18017df)
Merged
oranagra
pushed a commit
that referenced
this pull request
Feb 28, 2023
… than one key (#11854) Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb (which was unnecessary) This can potentially lead to use-after-free and memory corruption when the next entry pointer held by the watched keys iterator is freed when unwatching all keys of a specific client. found with address sanitizer, added a test which will not always fail (depending on the random dict hashing seed) problem introduced in #9829 (Reids 7.0) Co-authored-by: Oran Agra <oran@redislabs.com> (cherry picked from commit 18017df)
Would this also be a potential issue in |
no, because it doesn't iterate on the db->watched_keys, only works on a single key. |
Mixficsol
pushed a commit
to Mixficsol/redis
that referenced
this pull request
Apr 12, 2023
… than one key (redis#11854) Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb (which was unnecessary) This can potentially lead to use-after-free and memory corruption when the next entry pointer held by the watched keys iterator is freed when unwatching all keys of a specific client. found with address sanitizer, added a test which will not always fail (depending on the random dict hashing seed) problem introduced in redis#9829 (Reids 7.0) Co-authored-by: Oran Agra <oran@redislabs.com>
enjoy-binbin
pushed a commit
to enjoy-binbin/redis
that referenced
this pull request
Jul 31, 2023
… than one key (redis#11854) Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb (which was unnecessary) This can potentially lead to use-after-free and memory corruption when the next entry pointer held by the watched keys iterator is freed when unwatching all keys of a specific client. found with address sanitizer, added a test which will not always fail (depending on the random dict hashing seed) problem introduced in redis#9829 (Reids 7.0) Co-authored-by: Oran Agra <oran@redislabs.com>
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.
Avoid calling unwatchAllKeys when running touchAllWatchedKeysInDb (which was unnecessary)
This can potentially lead to use-after-free and memory corruption when the next entry pointer held by the watched keys iterator is freed when unwatching all keys of a specific client.
found with address sanitizer, added a test which will not always fail (depending on the random dict hashing seed)
problem introduced in #9829 (Reids 7.0)