On Tue, 26 Aug 2008, Jason McMullan wrote:
>
> All bets are off when data=writeback.
Not the way git writes pack-files. It does a fsync() before moving them
into place (at least newer git versions do), so the data is stable.
I do worry about wild pointers. I can't recognize the data, and it
definitely doesn't look like any git internal data structures, but 16-bit
data _is_ what zlib internally uses for things like the decoding tables.
So if there is some use-after-free issue, I could imagine things like this
happening inside of git. People do occasionally run valgrind on git,
though, and it's been clean in the past, but I don't know if that has ever
been done on the threaded packing, for example.
For example, the corrupting data had patterns like this:
00 f8 bf fe 6b 57 fe ff 55 57 fe ff 97 57 fe ff
where the pattern _could_ be something like
{ 00 f8 febf },
{ 6b 57 fffe },
{ 55 57 fffe },
{ 97 57 fffe },
assuming that the "fe ff" pattern really is meaningful and is a 16-bit
little-endian word.
And the thign is, zlib "code" tables look exactly like that:
typedef struct {
unsigned char op; /* operation, extra bits, table bits */
unsigned char bits; /* bits in this part of the code */
unsigned short val; /* offset in table or code value */
} code;
/* op values as set by inflate_table():
00000000 - literal
0000tttt - table link, tttt != 0 is the number of table index bits
0001eeee - length or distance, eeee is the number of extra bits
01100000 - end of block
01000000 - invalid code
*/
but those particular op/val things don't make sense in that context
either. But I don't know zlib that well, maybe the deflate routines use
some other model.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
