> 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: JpegQTableTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/33217/files - new: https://git.openjdk.org/jdk/pull/33217/files/261eb4ff..6d824dd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=33217&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=33217&range=00-01 Stats: 120 lines in 1 file changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/33217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33217/head:pull/33217 PR: https://git.openjdk.org/jdk/pull/33217
