Resource size hints appear to be used incorrectly when using compression

[Luke Hutchison]

Good info, I was wondering about the claims (in the ModuleReader javadoc)
about how ByteBuffer was being used for high-speed classloading, given that
in the past rt.jar has been compressed. This makes a lot more sense if the
system modules are not compressed.

So yes, the issues I raised are about the use of decompressed sizes in the
loading of resources from runtime images that were created with compression.


On Wed, Aug 8, 2018 at 6:22 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 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
>