Map bounds check #2938
Merged
Map bounds check #2938
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
nical
force-pushed
the
map_bounds_check
branch
2 times, most recently
from
c9bd036
to
6308d5e
Compare
jimblandy
approved these changes
Aug 3, 2022
|
The CI failures here are due to the macOS 10.15 deprecation. I've filed #2940 for that. |
|
... and it would be good to rebase this PR on that once it lands, so we can get a clean run before merging. |
map_async already checks that the range's end is within the bounds of the buffer, so this also ensures the range start is within bounds.
jimblandy
force-pushed
the
map_bounds_check
branch
from
6308d5e
to
ddc3581
Compare
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.
Checklist
cargo clippy.Connections
Fixes #2935.
Description
The range is not entirely bounds checked in buffer_map_async. It uses unsigned integers guaranteeing that the range can't underflow the buffer, and the range's end is also checked against the size of the buffer, but a user calling into wgpu_core directly (such as Firefox), could pass a negative range which is invalid and also would allow the start offset to be outside of the bounds of the buffer.
The fix is simply to validate that the range is not negative. Since the end of the range is already validated against the buffer size, it means the buffer start isn't allowed to overflow the buffer.
Testing
None.