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: http://source.git-repair.branchable.com/?p=source.git;a=blob;f=Git/Destroyer.hs -- see shy jo
Attachment:
signature.asc
Description: Digital signature