On 08/08/2018 06:19, Luke Hutchison wrote:
:
(2) size is used directly without restriction, rather than as a size hint.
ZipEntry#getSize() may actually return a totally bogus value (you can write
anything you want for the uncompressed size in a zipfile entry). If the
requested size is large, e.g. something close to Integer.MAX_VALUE, large
allocations will occur every time a resource is read, which can be used as
a memory allocation attack vector.
I've changed the subject line as the original subject line suggested an
issue with the module system. Instead, I think your mail is about
run-time images created with `jlink --compress <level>`. The JDK
run-time images do not use compression so the code paths in the jimage
code for compressed resources may not be tested as well as the
uncompressed case. If there are bugs or inefficiencies in the handling
of compressed resources then we should get them into JIRA.
-Alan
