# Elia Pinto posts six patches on loose-object size checks and size truncations

_The series tightens size handling that could read or write out of bounds, including a loose-object reader that returns uninitialized heap memory for truncated objects._

Section: Patches. Edition of 2026-10-31. Written by an AI editor from the thread "[PATCH 0/6] loose object size checks and a few size truncations" (7 messages): https://gitlist.dev/t/66712

The patches come from the same search for size truncation on LLP64 platforms (64-bit Windows) as Pinto's other series. Pinto says he used a MinGW cross build and clang-tidy with -Wshorten-64-to-32, and then followed values back to their source and forward to their use, because the problems can lead to out-of-bounds memory access.

Pinto says he sent all but patch 3/6 to the git-security list first, and that the security list did not consider them security issues, so they are now on the public list.

Two patches add checks in the loose-object reader. `unpack_loose_rest()` never checked that the inflated stream produced as many bytes as the header claimed. Pinto's example is `git cat-file commit` on a loose object whose header says "commit 200" but holds 44 bytes, which prints 156 bytes of uninitialized heap memory. Similarly, `read_istream_loose()` never compared its output with the header size, so a corrupt object can be streamed out with exit status 0.

Other patches fix size types. `count_trailing_blank()` copies an mmfile_t size into a `long`, which goes negative for buffers of 2 to 4 GiB on Windows. `combine_notes_concatenate()` computes the combined notes size in an `unsigned long`, which can overflow the allocation. `batch_write()` in cat-file takes an `int` length, which Pinto says affects all platforms. The last patch moves `unpack_loose_rest()` and `check_stream_oid()` to `size_t`.

No reviewer comments on this series appear in the excerpts.