Hello,
There is a possible 1-byte overflow in zipinfo.c (both unzip 6.0 and unzip 5.52).
In function  zi_short(__G), the variable hostver is in range 0-255. There is a sprintf call in that function, that uses attribs[16] array to create a string:

sprintf(attribs, ".r.-...     %u.%u", hostver/10, hostver%10);

If hostver >= 100, hostver/10 uses 2 characters, and attribs[16] is not large enough.
There are multiple calls of sprintf(&attribs[12], "%u.%u", hostver/10, hostver%10); in the same function that are also affected.

Increasing the size of attribs by 1 is a sufficient fix.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=532380 for more information and a test file.

> Increasing the size of attribs by 1 is a sufficient fix.

   That depends on your definition of "sufficient".  It might be, if
your _only_ goal is preventing this particular array bounds overrun, and
you don't care what happens to the report format, or the other code
which thinks that it knows the size of attribs[] (like, for example, the
piece which NUL-terminates the thing: "attribs[15] = 0;").  It might do
less damage to enforce the current assumption that hostver < 100.  For
example, change:
    hostver = (unsigned)(G.pInfo->hostver);
to:
    hostver = MIN( 99, (unsigned)(G.pInfo->hostver));
(in two places), which would seem to me to solve the problem without
wrecking all the other code which deals with attribs[].

Hi sms,
I see, hostver = MIN( 99, (unsigned)(G.pInfo->hostver)); is certainly better solution.
Thanks.

> [...] is certainly better solution.

   So, which fix got pushed back into the code?

I assume the question is directed to unzip's maintainer.
The former fix is currently used in Fedora, as it was already in place.

I also have been thinking about enforcing the G.pInfo->hostver < 100 when it is loaded in process_cdir_file_hdr() (file process.c), with a warning message. That would make the assumption fulfilled for the whole unzip.