fix(allocator): fix soundness hole in Allocator::alloc_bytes_start#13141
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
CodSpeed Instrumentation Performance ReportMerging #13141 will not alter performanceComparing Summary
Footnotes |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a soundness hole in Allocator::alloc_bytes_start that could lead to undefined behavior when called with extremely large size values. The fix prevents integer overflow during alignment calculations that could result in insufficient memory allocation.
- Replaces potentially overflowing addition with
saturating_addto handle edge cases safely - Adds comprehensive documentation explaining the overflow prevention strategy
- Ensures that oversized allocation requests will be properly rejected by downstream capacity checks
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
475f1ac to
baf116e
Compare
|
I don't think anyone has time to review, and I'm the one who knows this code best, so merging. |
Merge activity
|
…13141) Fix a bug in `Allocator::alloc_bytes_start` which could have resulted in UB. Previously, if called with `size: usize::MAX`, the rounding up calculation would wrap around so it would not allocate any space in the arena. This PR makes sure such a large `size` causes a panic as it should. In practice I don't think there was a real risk of `alloc_bytes_start` being called with such an absurdly large `size`, but regardless, we need to handle the edge cases.
baf116e to
8264664
Compare

Fix a bug in
Allocator::alloc_bytes_startwhich could have resulted in UB.Previously, if called with
size: usize::MAX, the rounding up calculation would wrap around so it would not allocate any space in the arena. This PR makes sure such a largesizecauses a panic as it should.In practice I don't think there was a real risk of
alloc_bytes_startbeing called with such an absurdly largesize, but regardless, we need to handle the edge cases.