On Mon, 12 Oct 2026 20:23:26 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). > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8393551 src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 728: > 726: > 727: for (j = 0; j < 64; j++) { > 728: quant_ptr->quantval[j] = (UINT16)qdataBody[j]; Converting the values from "int" to "unsigned short" can cause issues. 65536 can become 0 and then we clamp it to 1. We can just clamp directly without using UINT16 cast. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33217#discussion_r4258262415
