Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

crates.io package

sheets-diff

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.5crates.ioPublished

    A 512-byte workbook can provoke a multi-gigabyte allocation and abort the process

    GHSA-w5x2-6474-pqp4

    Affected
    • crates.io sheets-diff >= 0.0.0-0, < 3.2.0
    Fixed in
    3.2.0· Vendor fix available
    Issue
    Affected versions passed caller-supplied bytes to `calamine`'s `Xlsx::new` without first checking that they were a ZIP archive. `Xlsx::new` tests for password protection on its first line, which parses the input as an OLE/CFB container, and a sector-count field read from the file's own header reaches `Vec::with_capacity` without being checked against the file's actual length. A 512-byte input can therefore request several gigabytes; 9,261,285,372 bytes was measured. The oversized allocation is always attempted. Whether it aborts depends on what the allocator can satisfy. On a large host with overcommit the reservation is granted untouched and the call returns an ordinary "not an xlsx file" error, which looks like a malformed file being correctly rejected. Under a memory limit the same bytes give `memory allocation of N bytes failed` and the process aborts, which is not a `Result` a caller can handle. Containers with a memory limit, small hosts and CI runners are where this lands,…

    Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.devSource checked Evidence →