Arithmetic overflow found on `with_capacity()`
Open
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1.4k
- Forks
- 378
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 5
Description
I executed fuzz testing on http-0.2.9, and found some arithmetic overflow.
Please note that overflow condition is different with #626 .
pub fn with_capacity(capacity: usize) -> HeaderMap<T> {
if capacity == 0 {
HeaderMap {
mask: 0,
indices: Box::new([]), // as a ZST, this doesn't actually allocate anything
entries: Vec::new(),
extra_values: Vec::new(),
danger: Danger::Green,
}
} else {
let raw_cap = to_raw_capacity(capacity).next_power_of_two(); // overflow!
assert!(raw_cap <= MAX_SIZE, "requested capacity too large");
debug_assert!(raw_cap > 0);
HeaderMap {
mask: (raw_cap - 1) as Size,
indices: vec![Pos::none(); raw_cap].into_boxed_slice(),
entries: Vec::with_capacity(raw_cap),
extra_values: Vec::new(),
danger: Danger::Green,
}
}
}
reproduce with :
HeaderMap::<u32>::with_capacity(12538021362599493900); // put some big number here
If you input TOO big number on with_capacity(), #626 occurs before reaching to next_power_of_two().
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at HeaderMap::with_capacity and trace to_raw_capacity, then reproduce the reported large-capacity call, including the distinction from issue #626. Done means the reported input no longer causes arithmetic overflow while preserving the existing oversized-capacity behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100