On Mon, 5 Oct 2026 20:40:41 GMT, Phil Race <[email protected]> wrote:
> This adds some extra checks/validation affecting the ImageIO JPEG writer
> plugin
>
> The cases are
> - the constructor for a JPEGHuffmanTable validates the array parameters and
> copies after the validation. It would take the application to be doing
> something very odd for this to be a problem, but there's no cost in doing the
> copy before hand.
>
> - ImageIO's native JPEG library is compiled to support baseline JPEG only.
> This means 8 bit quantization values in the range 1 -> 255. the image I/o
> native glue code should enforce this.
>
> - The native glue code has no explicit check for null Huffman table data .
> This isn't normally possible, but direct manipulation of a meta data tree can
> be used to force it. In which case we have a null de-ref crash. A simple
> check for null should fix this. I was able to devise a test for this,
> although it is very contrived code.
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 734:
> 732: if (quant_ptr->quantval[j] > 255) { // ImageIO supports
> baseline only
> 733: quant_ptr->quantval[j] = 255;
> 734: }
There is a place where the clamp to 8-bit is used only if baseline is set,
otherwise the 16-bit is used: [int max = (forceBaseline) ? 255 :
32767;](https://github.com/openjdk/jdk/blob/f2fd22f7a23505bef47227a97a51bc9e1837111e/src/java.desktop/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java#L179).
I think it should be possible to trigger the usage of such JPEGQTable by the
test and confirm that the 16 is actually used when the image is saved/read?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33217#discussion_r4202934187
