Panic: subtraction overflow in ExtendedTimestamp::try_from_reader (v4.6.1)

[ozzieba]

Summary

ExtendedTimestamp::try_from_reader in src/extra_fields/extended_timestamp.rs panics with "attempt to subtract with overflow" when processing malformed ZIP files. This is a denial-of-service vulnerability when parsing untrusted ZIP archives.

Affected Version

• zip 4.6.1 (regression from 4.0.0 which correctly returns Err for this case)

Reproduction

Any malformed ZIP where the extended timestamp extra field (ID 0x5554) has a len value that, combined with the flags byte, causes unsigned integer underflow during the bytes_to_read -= size_of::<u32>() subtraction.

Found via coverage-guided fuzzing with cargo-fuzz/libfuzzer. Minimized crash inputs available on request.

Stack Trace

thread panicked at 'attempt to subtract with overflow'
  → extended_timestamp.rs:26
  → parse_single_extra_field (read.rs:1468)
  → parse_extra_field (read.rs:1377)
  → central_header_to_zip_file_inner (read.rs:1342)
  → ZipArchive::new

Root Cause

In v4.6.1, the try_from_reader function subtracts size_of::<u32>() from bytes_to_read without checking that bytes_to_read >= 4, causing unsigned integer underflow → panic.

Note: v4.0.0 had proper validation at this location:

if len != 5 && len as u32 != 1 + 4 * flags.count_ones() {
    return Err(ZipError::UnsupportedArchive("flags and len don't match..."));
}

This validation appears to have been removed or bypassed in v4.6.1.

Suggested Fix

Use checked_sub or add a bounds check before the subtraction:

bytes_to_read = bytes_to_read.checked_sub(size_of::<u32>())
    .ok_or(ZipError::InvalidArchive("extended timestamp field too short"))?;

Impact

• Severity: Medium (DoS via panic on untrusted input)
• Attack vector: Any application that parses untrusted ZIP files using this crate
• Workaround: Pin to =4.0.0 or wrap ZipArchive::new() in catch_unwind

[Its-Just-Nans]

Hi

Did you try with the latest version?

[ozzieba]

sorry this was a rogue agent that should not have had gh creds; may still be correct but I cannot vouch for it; fwiw it says the bug was introduced in 4.6.1