Bad virtual array access when JVM is built with jpeg-turbo instead of bundled jpeg library

[Dennis4b]

Firstly I apologize this does not follow the bug report layout, nor can be reproduced with only libjpeg-turbo, but I found some old fixes in libjpeg-turbo which refer to a similar problem.

I am trying to find out where to look to further debug the following:

Using the Java OpenJDK 11 or up (not yet JDK 8), using ImageIO to open a JPEG file throws for certain files the following error:

Exception in thread "main" javax.imageio.IIOException: Bogus virtual array access
	at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage(Native Method)
	at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:1318)
	at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:1110)
	at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468)
	at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1315)
	at ImageExceptionMain.main(ImageExceptionMain.java:10)

where readNative is in the JVM's own libjavajpeg.so which uses libjpeg-turbo, currently version 2.1.3.

This happens on both FreeBSD and Arch Linux builds of OpenJDK, both of which default to using the system jpeg library (libjpeg-turbo version 2.1.3)

If I compile the JDK with --libjpeg=bundled, which uses a jpeg reference implementation, everything works fine.

It is easy to reproduce from Java, please see the java source code below and an example image file (no affiliation to its contents!)

I could not reproduce any problem with the standard libjpeg-turbo binaries themselves, so again apologies if this has nothing to do with libjpeg-turbo itself.

To reproduce create ImageExceptionMain.java with the following contents:

import java.io.File;
import java.io.IOException;
import javax.imageio.*;
import java.awt.image.BufferedImage;


public class ImageExceptionMain {

    public static void main(String[] args) throws IOException {
        BufferedImage image = ImageIO.read(new File("image.jpg"));
    }
}

and run

javac ImageExceptionMain.java && java ImageExceptionMain 

with an OpenJDK version 11 or 17 that was compiled with system-jpeg libraries.

with the following image file (I hope github does not modify it in some way):

but just in case it does here it is attached as a zipped file:

image.zip

[dcommander]

Unfortunately there is little I can do with that information. I would have to spend hours building the JDK from source code, and my experience suggests that the most likely diagnosis will be a bug in the calling program, not a bug in libjpeg-turbo. After about the fifth time that I wasted a day trying to track down a bug in libjpeg-turbo that wasn’t actually a bug in libjpeg-turbo, I started requiring that a bug be reproducible with libjpeg-turbo in isolation before I will investigate it. I usually have to use the libjpeg-turbo General Fund in order to investigate such issues, and that fund only pays for 8-10 hours of labor per month. It could easily take more time than that just to get to the point of reproducing this issue.

[dcommander]

What I can tell you is that the error message (“Bogus virtual array access”) is generally thrown by the libjpeg memory manager when the calling program tries to access an image array beyond its allocated bounds. As to why the calling program is triggering that error only with libjpeg-turbo, I have no idea.

[Dennis4b]

That's fair. Thank you for your reply, I will keep debugging this and post my findings here.

[Dennis4b]

(Posting this update in case it rings a bell already based on the description, but I'll keep digging)

The difference between djpeg and the JVM is the following (note that the input is a progressive JPEG)

The JVM sets cinfo.buffered_image = TRUE, djpeg does not.

After jpeg_start_decompress, the cinfo.input_scan_number for djpeg has been updated to (for this image) 10, for the JVM it remains at 1.

Then when smoothing_ok(..) is called:

    if (cinfo->do_block_smoothing && smoothing_ok(cinfo))

it returns TRUE for the JVM, but FALSE for djpeg.

      if (cinfo->input_scan_number > 1)
        prev_coef_bits_latch[coefi] = prev_coef_bits[coefi];
      else
        prev_coef_bits_latch[coefi] = -1;

      if (coef_bits[coefi] != 0) {   
        smoothing_useful = TRUE; 
      }

The bogus array access is then thrown via decompress_smooth_data in access_virt_barray:

 if (end_row > ptr->rows_in_array || num_rows > ptr->maxaccess ||
      ptr->mem_buffer == NULL) {

// fails because end_row = 3 and ptr->rows_in_array = 1

If I make smoothing_ok return FALSE then everything works.

(When the JVM uses its internal reference jpeg implementation the smoothing_ok method is much simpler and also returns FALSE)

So this should basically be reproducible if djpeg is modified to use cinfo.buffered_image = TRUE, which will cause smoothing_ok to return TRUE and trigger the error in the decompress_smooth_data variant.

I will try to produce such an example, I guess there would be 4 possible outcomes:

1. The JVM does something not according to spec
2. The smoothing_ok returns TRUE when it shouldn't for this image
3. There is a bug in decompress_smooth_data, or
4. The image is somehow corrupted causing decompress_smooth_data to fail

[dcommander]

That is good information and does point to the possibility of a bug in the smoothing enhancements introduced in libjpeg-turbo 2.1. I will investigate.

[dcommander]

Reproduced the issue with the following patch:

--- a/djpeg.c
+++ b/djpeg.c
@@ -710,8 +710,13 @@ main(int argc, char **argv)
   dest_mgr->output_file = output_file;
diff --git a/djpeg.c b/djpeg.c
index d47984e6..871849c5 100644
--- a/djpeg.c
+++ b/djpeg.c
@@ -710,8 +710,13 @@ main(int argc, char **argv)
   dest_mgr->output_file = output_file;
 
   /* Start decompressor */
+  cinfo.buffered_image = TRUE;
   (void)jpeg_start_decompress(&cinfo);
 
+  while (!jpeg_input_complete(&cinfo)) {
+
+  (void)jpeg_start_output(&cinfo, cinfo.input_scan_number);
+
   /* Skip rows */
   if (skip) {
     JDIMENSION tmp;
@@ -846,6 +851,10 @@ main(int argc, char **argv)
    * I must do it in this order because output module has allocated memory
    * of lifespan JPOOL_IMAGE; it needs to finish before releasing memory.
    */
+
+  jpeg_finish_output(&cinfo);
+  }
+
   (*dest_mgr->finish_output) (&cinfo, dest_mgr);
   (void)jpeg_finish_decompress(&cinfo);
   jpeg_destroy_decompress(&cinfo);

and verified that 6d91e95 is the cause.

[dcommander]

I think I have a solution. Stand by. Since this is the weekend, I probably won't be able to push it until tomorrow.

[dcommander]

Should be fixed now. Please test and let me know.