gix-pack

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

Multiple denial-of-service vectors in gix-pack: unchecked array indexing causes panics on crafted delta data, and uncapped attacker-controlled size headers enable OOM process kills. Both are triggered by malicious pack data received during clone/fetch.

Details

Bug 1: Unchecked array indexing in delta application (CWE-248)

The apply() function in gix-pack/src/data/delta.rs (lines 33-87) reads delta instructions using unchecked data[i] indexing at 7 locations (lines 41, 45, 49, 53, 57, 61, 65). The command byte's bits indicate how many additional bytes follow, but if the delta data is truncated, the index panics:

pub(crate) fn apply(base: &[u8], mut target: &mut [u8], data: &[u8]) -> Result<(), apply::Error> {
    let mut i = 0;
    while let Some(cmd) = data.get(i) {  // first byte: safely checked
        i += 1;
        match cmd {
            cmd if cmd & 0b1000_0000 != 0 => {
                let (mut ofs, mut size): (u32, u32) = (0, 0);
                if cmd & 0b0000_0001 != 0 {
                    ofs = u32::from(data[i]);     // PANIC: no bounds check
                    i += 1;
                }
                // ... 6 more unchecked data[i] at lines 45, 49, 53, 57, 61, 65

Lines 83-84 use assert_eq! (not debug_assert_eq!) that panics in both debug and release builds:

    assert_eq!(i, data.len());
    assert_eq!(target.len(), 0);

A second location in parse_header_info() (gix-pack/src/data/entry/decode.rs:116-129) also panics on truncated input via unchecked data[0] and data[i].

Note: PR #2059 (merged 2025-06-25) fixed the explicit panic!() for command code 0. The unchecked array indexing is a distinct class that remains unfixed.

Bug 2: Uncapped allocation from attacker-controlled size headers (CWE-770)

Pack entry headers and delta headers encode object sizes as LEB128-encoded u64 values. These sizes are used to allocate buffers before validating the actual data, with no upper bound:

bytes_to_entries.rs:109  Vec::with_capacity(entry.decompressed_size as usize)  // UNCAPPED
resolve.rs:461           out.resize(decompressed_len, 0)                       // UNCAPPED
resolve.rs:190           fully_resolved_delta_bytes.resize(result_size as usize, 0)  // UNCAPPED

A 10-byte crafted pack entry can claim decompressed_size = 0xFFFFFFFFFFFF (281 TB). At bytes_to_entries.rs:109, gitoxide calls Vec::with_capacity(281TB) before any decompression occurs. The OS immediately OOM-kills the process. No MAX_SIZE, max_object_size, or equivalent limit exists anywhere in gix-pack.

The allocation at resolve.rs:461 is equally dangerous: decompressed_size from the pack header is cast to usize and passed to Vec::resize(), which allocates and zeroes the full claimed size before the zlib decompressor runs.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All 5 panics confirmed:

[1] delta apply: cmd=0x81, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[2] delta apply: cmd=0xFF, only 3 extra bytes -> PANIC: index out of bounds: len is 4 but index is 4
[3] parse_header_info: empty data -> PANIC: index out of bounds: len is 0 but index is 0
[4] parse_header_info: byte=0x80, truncated -> PANIC: index out of bounds: len is 1 but index is 1
[5] delta apply: assert_eq!(i, data.len()) -> PANIC: assertion failed

For the OOM vector: the allocation path is parse_header_info() -> entry.decompressed_size (u64) -> Vec::with_capacity(size as usize) with no intermediate validation. A minimal pack with a single entry claiming a multi-terabyte size triggers immediate process kill.

Impact

Any application built on gitoxide that clones or fetches from an untrusted remote can be crashed by a malicious server:

• Panic DoS: 1-2 bytes of crafted delta data causes an immediate process abort
• OOM DoS: A single crafted pack entry header causes the process to attempt a multi-terabyte allocation, triggering an immediate OOM kill by the OS

This affects the gix CLI, any application using the gix crate, and CI/CD systems that clone repositories using gitoxide. No fuzz targets exist for gix-pack (issue #703 tracks oss-fuzz integration).

Suggested fix

For panics: replace unchecked data[i] with data.get(i).ok_or(Error::...) and replace assert_eq! with proper error returns.

For OOM: add a configurable maximum object size (similar to git's transfer.maxPackSize) and validate claimed sizes against it before allocating. At minimum, cap allocations to a reasonable default (e.g., 4 GB) and use try_reserve() consistently.

Severity

High. Network vector, no privileges required, user interaction required (clone/fetch). The OOM vector is a single-packet process kill with no recovery.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC