Fix potential integer overflow in hash container create/resize #1813
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.
The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store. Subsequent accesses to the container might then access out-of-bounds memory.
The fix is in two parts:
Update max_size() to return the maximum number of items that can be stored in the container
Validate the size arguments to the constructors, reserve(), and rehash() methods, and abort the program when the argument is invalid
We've looked at uses of these containers in Google codebases like Chrome, and determined this vulnerability is likely to be difficult to exploit. This is primarily because container sizes are rarely attacker-controlled.
The bug was discovered by Dmitry Vyukov [email protected].