memory overrun bug

[der Mouse]

If my reading of the code is correct, certain (corrupted) archives can
cause tar to access memory outside of a mallocked chunk.  I noticed
this with 1.11.2; 1.13 appears to have the same problem, though the
variable names have changed (the discussion below uses the 1.11.2
names).

In extract_archive(), in extract.c, case LF_SPARSE, if a chunk's
numbytes value is zero, it is apparently taken as end-of-file, in that
it indicates a break from the relevant loop.  However, further header
blocks are processed based on isextended, not on whether a zero
numbytes has been found.

Furthermore, when sparsearray is extended, it is extended by simply
doubling its current size, regardless of whether that's enough for the
about-to-be-used index.  And it starts at size 10.

Thus, consider:

First header: LF_SPARSE, isextended set -> extension header block is
        read
First extension header: ext_hdr.sp[0].numbytes contains zero,
        isextended is nevertheless set -> sparsearray is not extended,
        because the loop is broken before i gets high enough
Second extension header: i will be zero, ind will be 25; sparsearray
        will be extended to 20, twice its present size (10).
        ext_hdr.sp[0] will then be converted and stored in
        sparsearray[25], thereby overrunning sparsearray.

Surely this is not right.  It seems to me that the basic problem is
that the same information (have we reached the end of the sparse chunk
descriptors?) is being stored in two places (descriptor with numbytes
zero, or isextended being clear).  This doesn't seem right to me.

Or...Am I Missing Something?

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               address@hidden
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B