The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However, the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage` code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops. Testing: - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests. - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after. - [ ] GHA. In progress. Thoughts? ------------- Commit messages: - 8302337: JDK crashes if lib/modules contains non-zero ATTRIBUTE_END bytes Changes: https://git.openjdk.org/jdk/pull/12539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302337 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12539.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12539/head:pull/12539 PR: https://git.openjdk.org/jdk/pull/12539
