JDK-6740544 : mismatch of signed, unsigned values causes mmap failure
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2008-08-22
  • Updated: 2010-04-02
  • Resolved: 2009-05-13
Related Reports
Duplicate :  
JDK-4681995 - Add support for large (> 4GB) zip/jar files
Description
In zip_util.h, macros are defined to access header fields, e.g.
#define LG(b, n) (SH(b, n) | (SH(b, n+2) << 16))
...
#define ENDSIZ(b) LG(b, 12)	    /* central directory size */

These are used in zip_util.c, e.g.
    cenlen = ENDSIZ(endbuf);
    if (cenlen > endpos)
	ZIP_FORMAT_ERROR("invalid END header (bad central directory size)");

cenlen is declared as a jlong, which is signed.  If the value returned from ENDSIZ has the high order bit set, cenlen is negative, and definitely less than endpos.  The value of cenlen is used (indirectly) in a call to mmap, which results in

mmap failed for CEN and END part of zip file
Comments
EVALUATION The LG micro has already been patched as #define LG(b, n) ((SH(b, n) | (SH(b, n+2) << 16)) &0xffffffffUL) in the work for #4681995(the > 4G zipfile support) to guarantee its "unsighen 32 -bit". Tests show the latestest zip/jar works pretty well with 2G-4G zipfile (which fall in the range of this 32-bit signed and unsigned gap. The fix for #6599383 ( > 2G zipfle) is also related, which has already been in 6ux and 7. Closed as the "dup" of #4681995. (backport the LG micro part of the fix).
13-05-2009
EVALUATION Signed values are used in a few places where unsigned should be used.
22-08-2008
SUGGESTED FIX Use unsigned values instead of signed where appropriate.
22-08-2008