Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-02-25 Thread Jeff King
On Wed, Feb 24, 2016 at 10:48:27AM -0800, Junio C Hamano wrote: > >> We do not check if the offset of individual objects are within the > >> corresponding .pack file, either, and nth_packed_object_offset() > >> does return the data read from .idx file that is not checked for > >> sanity.

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-02-24 Thread Junio C Hamano
Jeff King writes: > On Thu, Jan 07, 2016 at 02:54:50PM -0800, Junio C Hamano wrote: > >> We do not check if the offset of individual objects are within the >> corresponding .pack file, either, and nth_packed_object_offset() >> does return the data read from .idx file that is not

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-02-24 Thread Jeff King
On Thu, Jan 07, 2016 at 02:54:50PM -0800, Junio C Hamano wrote: > We do not check if the offset of individual objects are within the > corresponding .pack file, either, and nth_packed_object_offset() > does return the data read from .idx file that is not checked for > sanity. use_pack(), which

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-06 Thread Jacek Wielemborek
W dniu 06.01.2016 o 01:23, Jonathan Nieder pisze: > Jeff King wrote: > >> Git packfiles come from two places: >> >> 1. Local maintenance repacks loose and already-packed objects into a >> new packfile. We trust the local repack process to generate a valid >> packfile (though the

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-06 Thread Duy Nguyen
On Tue, Jan 5, 2016 at 10:24 PM, Jeff King wrote: > If you can find a fuzzed packfile that crashes "index-pack", then _that_ > would be a big deal. I'm sure you know this, but if Jacek moves to break index-pack, then he/she should also try to break unpack-objects because sometimes

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-06 Thread Jacek Wielemborek
W dniu 06.01.2016 o 10:46, Duy Nguyen pisze: > On Tue, Jan 5, 2016 at 10:24 PM, Jeff King wrote: >> If you can find a fuzzed packfile that crashes "index-pack", then _that_ >> would be a big deal. > > I'm sure you know this, but if Jacek moves to break index-pack, then > he/she

Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-05 Thread Jacek Wielemborek
Hello, Steps to reproduce: 1. base64 -d and unpack the .tar.gz file from here: https://gist.github.com/d33tah/4e976f2e043718594a85 2. cd into it, run "git log" I'll be happy to guide you through the fuzzing process - I stopped it at the first crash. Cheers, d33tah signature.asc

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-05 Thread Jeff King
On Tue, Jan 05, 2016 at 02:44:49PM +0100, Jacek Wielemborek wrote: > Steps to reproduce: > > 1. base64 -d and unpack the .tar.gz file from here: > https://gist.github.com/d33tah/4e976f2e043718594a85 > > 2. cd into it, run "git log" > > I'll be happy to guide you through the fuzzing process - I

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-05 Thread Jeff King
On Tue, Jan 05, 2016 at 04:23:33PM -0800, Jonathan Nieder wrote: > > Git packfiles come from two places: > > > > 1. Local maintenance repacks loose and already-packed objects into a > > new packfile. We trust the local repack process to generate a valid > > packfile (though the

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

2016-01-05 Thread Jonathan Nieder
Jeff King wrote: > Git packfiles come from two places: > > 1. Local maintenance repacks loose and already-packed objects into a > new packfile. We trust the local repack process to generate a valid > packfile (though the contents of individual objects may be > untrusted, of