Arithmetic overflow found on `with_capacity()`
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 42/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- rust
调研方向
从 HeaderMap::with_capacity 开始,跟踪到 to_raw_capacity,然后重现报告中的大容量调用,包括与 issue #626 的区别。完成的标准是:报告中的输入不再导致算术溢出,同时保留现有的超大容量行为。
由索引模型根据 Issue 内容生成。
描述
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().
- 主要语言
- Rust
- 星标
- 1.4k
- 派生
- 378
- 平均合并
- 1 天 21 小时
- 30 天内合并 PR
- 5
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
hyperium/http 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 4/5 3-5 天 新手友好度 45/100
-
难度 3/5 1-2 天 新手友好度 62/100
-
难度 3/5 1-2 天 新手友好度 58/100
-
难度 3/5 1-2 天 新手友好度 62/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
TheLarkInn/aipm#2413 ·
-
documentation
难度 1/5 1 小时以内 新手友好度 90/100
alexgorbatchev/simple-ptt#15 ·
-
tooling
难度 2/5 1-3 小时 新手友好度 75/100
-
todo:ticket
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 75/100
taikoxyz/taiko-mono#22168 · 1 条评论 ·