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.bate...@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 >
