Jeff King wrote:
> > BTW, I've also seen git cat-file --batch report wrong sizes for objects,
> Hrm. For --batch, I'd think we would open the whole object and notice
> the corruption, even with the current code. But for --batch-check, we
> use sha1_object_info, and for an "experimental" object, we do not need
> to de-zlib the object at all.  So we end up reporting whatever crap we
> decipher from the garbage bytes.  My patch would fix that, as we would
> not incorrectly guess an object is experimental anymore.
> If you have specific cases that trigger even after my patch, I'd be
> interested to see them.

I was seeing it with --batch, not --batch-check. Probably only with the
old experimental loose object format. In one case, --batch reported a
size of 20k, and only output 1k of data. With the object file I sent
earlier, --batch reports a huge size, and fails trying to allocate the
memory for it before it can output anything.

I also have seen at least once a corrupt pack file that caused git to try
and allocate a absurd quantity of memory.

Unfortunately I do not currently have exemplars for these, although I
should be able to run a less robust version of my code and find them
again. ;) Will try to find time to do that.

BTW, the fuzzing code is here:;a=blob;f=Git/Destroyer.hs

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply via email to