git2-rs icon indicating copy to clipboard operation
git2-rs copied to clipboard

Null pointer dereference in `git_remote_fetch`

Open demurgos opened this issue 3 years ago • 3 comments

  • Initially reported at https://github.com/rust-lang/git2-rs/issues/813#issuecomment-1063449132
  • Full reproduction
  • Git2 version 0.14.1, with the feature vendored-libgit2

The following Rust programs triggers a segfault due a null pointer dereference in git_remote_fetch:

use git2::{AutotagOption, FetchOptions, Repository, RepositoryInitOptions};
use std::path::PathBuf;

fn main() {
    let input_path = PathBuf::from("./git2");
    let remote_url = "https://gitlab.com/eternaltwin/popotamo/popotamo.git".to_string();
    let commit = "d48338d82864679ed3bc656d7f7d1c445ac991b2".to_string();

    std::fs::create_dir_all(input_path.as_path()).expect("create_dir");

    let mut init_opts = RepositoryInitOptions::new();
    init_opts.mkpath(false);
    init_opts.mkdir(false);
    init_opts.external_template(false);
    let repository = Repository::init_opts(&input_path, &init_opts).expect("init repp");

    let mut remote = repository.remote_anonymous(&remote_url).expect("create remote");
    {
        let mut fetch_opts = FetchOptions::new();
        fetch_opts.download_tags(AutotagOption::All);
        let all_refs: [&str; 3] = ["master", "develop", &commit];
        remote.fetch(&all_refs, Some(&mut fetch_opts), None).expect("fetch");
    }
    eprintln!("done");
}

I initially thought it to be related to #813 as the problem only appeared recently: everything worked fine a few days ago. Since then I updated my system but did not touch my cargo lock file or config. However, according to @saethlin, this is a different bug.

demurgos avatar Mar 10 '22 00:03 demurgos

Thanks for putting together the reproduction. I have filed https://github.com/libgit2/libgit2/issues/6243 with upstream.

A workaround is to use a refspec with a destination, as in +d48338d82864679ed3bc656d7f7d1c445ac991b2:d48338d82864679ed3bc656d7f7d1c445ac991b2.

ehuss avatar Mar 11 '22 20:03 ehuss

It looks like the issue is fixed in upstream libgit2, the vendored version needs to be updated:

  • git2 = { version = "0.14.1", features = ["vendored-libgit2"] } (original) -> failing
  • git2 = { version = "0.14.2", features = ["vendored-libgit2"] } -> failing
  • git2 = { version = "0.14.1" } (system libgit2 - up-to-date) -> passes now

demurgos avatar Apr 19 '22 16:04 demurgos

Yep. I've been preparing a bump, but there are some snags that are delaying it. Hopefully soon!

ehuss avatar Apr 19 '22 17:04 ehuss