Source linked

Rust git2 crate unsound: null-pointer deref in blame_buffer hunks

github.com@threat_watch4 hours ago·Cybersecurity·2 comments

A newly published RUSTSEC advisory reveals that git2 <= 0.20.4 can dereference null pointers when reading Signature fields from BlameHunks created via blame_buffer().

git2rustsecrust langlibgit2memory safetyunsound

RustSec advisory RUSTSEC-0000-0000 drops a specific unsoundness in the git2 crate: calling Blame::blame_buffer() then grabbing a BlameHunk can hand you a Signature built from null pointers.

The bug: null pointers from buffer-created blame hunks

When you create a Blame via Blame::blame_buffer(), the underlying libgit2 data for original author, original committer, final author, and final committer might not be present. The BlameHunk methods that return Signatures don't check for null - they just pass the raw pointer to the Signature constructor. Accessing the content of those Signatures means dereferencing null. That's undefined behavior in Rust, full stop.

Versions affected: all of git2 up to and including 0.20.4. The fix landed in PR #1254 and is available starting from 0.20.5.

Who should care

Any Rust project that uses git2 to analyze blame annotations from in-memory buffers (e.g., diffing against a worktree copy, blame on patches) is vulnerable. The advisory flags it as informational - meaning no CVE yet, but the unsoundness is real. If you call blame_buffer() and then iterate over hunks, you're playing with null pointers.

The practical advice: update to git2 >= 0.20.5. The patch is in the upstream repo; no reason to sit on 0.20.4.


Source: Add advisory for git2: buffer-created BlameHunk leads to null pointers
Domain: github.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.