Integer overflow in deallocation
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- rust
調査の方向性
Start at src/hole.rs around line 617 and compare the reported deallocation values with the minimized psram.rs example and the large_deallocation test. Investigate why the test does not reproduce the overflow despite using the same arena size, allocation, and alignment. Done means the reported deallocation no longer panics and a regression test covers the case.
索引モデルが issue の本文から書いたものです。
説明
Thanks for this crate!
I tried to find the size of my PSRAM by simply allocating large amounts of data with a Vec and stumbled upon an integer overflow:
When trying to free an allocation with size 1048572 and alignment 4, my program panicked at https://github.com/rust-osdev/linked-list-allocator/tree/main/src/hole.rs#L617
I added a few panics to see some variable and argument values. The panic happens with this addition arguments: 1048572 += 4294967295 where the right-hand side is usize::MAX for this architecture.
I tried on the latest release 0.10.5 first but could also reproduce on the latest main commit
Minimized example:
https://github.com/ede1998/ireplay/blob/86e2f72509eaf308c133086e1daa133819e68852/src/bin/psram.rs
I tried to reduce the case even further by writing a test in this crate but could not reproduce it that way even though I compiled and ran it with 32bit x86 instead of 64 bit to ensure that usize::MAX is the same. As far as I could tell, there should be no significant difference between my minimized example and the test in terms of code: Both init an arena of the same size and then allocate and deallocate the same number of bytes with the same alignment.
Command
CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER=$( nix eval --raw --impure --expr 'let pkgs = import {}; in "${pkgs.pkgsi686Linux.stdenv.cc}/bin/${pkgs.pkgsi686Linux.stdenv.cc.targetPrefix}cc"');cargo test --target=i686-unknown-linux-gnu large_deallocation
#[test]
fn large_deallocation() {
// static mut ARENA: [MaybeUninit<u8>; 3_000_000] = [MaybeUninit::uninit(); 3_000_000];
// let mut heap = Heap::from_slice(unsafe { &mut ARENA });
static mut ARENA: [u8; 3_000_000] = [0; 3_000_000];
let mut heap = Heap::empty();
unsafe {
heap.init(ARENA.as_mut_ptr(), 2097152);
}
let layout = Layout::from_size_align(1048572, 4).unwrap();
let data = heap
.allocate_first_fit(layout)
.expect("Succesful allocation");
unsafe {
heap.deallocate(data, layout);
}
}
- 主要言語
- Rust
- スター
- 242
- フォーク
- 56
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
rust-osdev/linked-list-allocator のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
rust-osdev/linked-list-allocator#86 · リアクション 3 件 ·
-
help wanted
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
rust-osdev/linked-list-allocator#83 · コメント 2 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
rust-osdev/linked-list-allocator#76 · コメント 3 件 ·
rust-osdev/linked-list-allocator の issue をすべて見る
似ている issue
-
area: dogs area: lookout bug security
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
メンテナーはふだん 2 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
OpenDevicePartnership/ina4230#31 ·
メンテナーはふだん 1 日以内に返信
-
area:breg criticality:p3 documentation triage:needs-implementation
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
registrystack/registry-stack#1713 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
posit-dev/ggsql#565 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信