Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Integer overflow in deallocation

Ouverte
#85 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
rust

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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);
    }
}
Langage dominant
Rust
Étoiles
242
Forks
56
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rust-osdev/linked-list-allocator

Toutes les issues de rust-osdev/linked-list-allocator

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.