On Tue, 13 Oct 2026 22:32:21 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 I will capture the observation i have made while analysing this PR: Without clamping code: Not using explicit image param: Reading: Even if JPEG image has 8/16bit values in QTables, pixel decoding happens without any issue. But if we try to get Metadata for image with 16bit values in QTable, we will get IIOException. Writing: Wrting JPEG image uses the default QTables and all of them have 8bit values. Using explicit image param: Reading: QTable passed from image param will be used only if the JPEG stream doesn’t contain a QTable. When QTable passed from param is used values are not clamped. Writing: QTable passed from image param/dqtable node can be used and they will not be clamped. =============================================================================================================================== With clamping code: Not using explicit image param: Reading: No behaviourial change. Writing: No behaviourial change. Using explicit image param: Reading: QTable passed from image param will be used only if the JPEG stream doesn’t contain a QTable. When QTable passed from param is used and if the values are not 8bit they will be clamped. Writing: QTable passed from image param/dqtable node can be used and they will be clamped if the values are not 8bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33217#issuecomment-6190950217
