## Basic information Project name: Eclipse OpenJ9 Project id: technology.openj9 ## What are the affected versions? Confirmed present at tag `openj9-0.62.0` (source review) and dynamically reproduced against the official `ibm-semeru-runtimes:open-21.0.10_7.1-jdk` Docker image, bundled OpenJ9 0.57.0, commit `f0754f410244ad2c42b07c5fe76983a3c7b61e87`. Confirmed via the file's own commit history (`RawTypeConvert.hpp` has exactly 11 commits total): every commit after the file's introduction on 2020-03-17 is non-functional (clang-format reformatting in 2026-02, SPDX license identifier fix in 2023, copyright year update in 2023, a URL domain rename in a comment in 2022). No commit anywhere in the file's history touches the vector-decoding loop's logic. This means the vulnerable code has been present, unchanged, from JITServer's original introduction in 2020 through the current `main` branch, so this affects every released OpenJ9 version that includes the JITServer feature, the same version range as the two already-reported sibling findings (work items #940 and #941). ## Details of the issue Vulnerable source, at the exact commit this PoC was tested against: - https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/RawTypeConvert.hpp (the unbounded loop, `RawTypeConvert<std::vector<T>>::onRecv()`) - https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/Message.hpp (`DataDescriptor::getNextDescriptor()`, the unchecked pointer advance) - https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/control/JITServerCompilationThread.hpp (the `CompilationRequest` tuple layout, field 8 is the target) Also confirmed unchanged at the `openj9-0.62.0` tag used for the original static review: - https://github.com/eclipse-openj9/openj9/blob/openj9-0.62.0/runtime/compiler/net/RawTypeConvert.hpp `RawTypeConvert<std::vector<T>>::onRecv()` decodes a `uint32_t` element count from the incoming message with no check against the message's actual remaining size, then loops that many times calling `DataDescriptor::getNextDescriptor()` (`runtime/compiler/net/Message.hpp`), which just advances a pointer by a declared size field with no bounds check at all. This is the same root cause as the already-reported OOB-read finding (work item #941), but a different code path: that one is a single out-of-bounds read, this one is an unbounded loop that walks further past legitimately-received memory on every iteration until it dereferences an unmapped page. Reached via `MessageType::compilationRequest` (ordinal 8), the first message type read on a fresh connection, before any auth or version negotiation completes (`fullVersion=0` bypass, same as the two already-reported findings). The vulnerable field is field 8 of the `CompilationRequest` tuple, `std::vector<TR_OpaqueClassBlock *>`. Confirmed with a real crash. A test client sent a well-formed `compilationRequest` with every field valid except field 8, which declared an element count of 5,000,000. The server crashed with SIGSEGV. Register R14 held `0x004C4B40` (5,000,000 decimal, the injected count, live at crash time). Register R13 (`0x1A8B3` = 108,467) shows the loop ran over 100,000 iterations before the fault, confirming the iterative nature of this bug versus the single-shot read in #941. Stack trace matches the predicted chain: `GetArgsRaw` -> `ServerStream::readCompileRequest` -> `CompilationInfoPerThreadRemote::processEntry`. ## Impact `jitserver` is a shared, long-running network service: IBM's own documented use case is one JITServer instance serving compilation requests for multiple client JVMs at once (a multi-tenant deployment model). A single 956-byte message from an unauthenticated network peer, no credentials, no prior interaction, crashes the whole process with SIGSEGV, taking down compilation service for every client currently attached to that JITServer instance, not just the connecting peer. The crash is deterministic and repeatable at will: an attacker who can reach the JITServer port can force this at any time. This is a pre-auth remote denial-of-service, not an information-disclosure or code-execution finding; no working code-execution path is claimed here or in the two sibling findings. ## Severity `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` = 7.5 (High). Network-reachable, low attack complexity (single well-formed message, no timing/race requirement), no privileges or user interaction required, no confidentiality or integrity impact demonstrated, high availability impact (total, repeatable loss of the JITServer process). Same severity class as the already-reported CPU-hang DoS finding in this same family (work item #940). ## Steps to reproduce 0. Prerequisites: Docker installed and running, outbound network access to pull the image, port 38402 free on the test host, Python 3 for the test-client scripts (`send_baseline.py`, `send_crash_poc.py`, attached). 1. Pull and start the official image: `docker run -d --name jitserver-vecwalk -p 38402:38400 ibm-semeru-runtimes:open-21.0.10_7.1-jdk /opt/java/openjdk/bin/jitserver`. Confirm it is ready via `docker logs jitserver-vecwalk`. {width=900 height=576} 2. Run `send_baseline.py` (field 8 = empty vector) to confirm the connection and field layout are correct. Server replies normally, process stays alive. {width=900 height=576} 3. Run `send_crash_poc.py` (field 8 declares element count = 5,000,000, every other field left well-formed). Connection closes with no reply. {width=900 height=576} 4. `docker logs jitserver-vecwalk` shows the crash: SIGSEGV, register R14 holding the injected count (0x004C4B40 = 5,000,000). {width=900 height=576} 5. Same log, stack trace, matches the predicted vulnerable call chain. {width=900 height=576} 6. `docker ps -a` confirms the container process exited (255) at the same time as the crash. {width=900 height=576} Full write-up, both PoC scripts, and the raw `docker logs` crash dump are attached below. ## Do you know any mitigations of the issue? Same fix direction as the already-reported single-shot OOB-read finding: bound the loop count against the message's actual remaining declared size before iterating, in addition to (not instead of) the existing top-level `MessageBuffer::readData()` check, since that check never recurses into nested vector decoding. [send_crash_poc.py](/uploads/6d7d1438e1557d706509bcc4da722698/send_crash_poc.py) [send_baseline.py](/uploads/fd15f0bff0ce7be9dc07d3bb266a52c7/send_baseline.py) [crash_log_live.txt](/uploads/0d60e76ba5544f0c2b88c66f4238a280/crash_log_live.txt) [POC-openj9-jitserver-vector-heapwalk-crash.md](/uploads/3177725a59fc23ece86576ca0554c5d8/POC-openj9-jitserver-vector-heapwalk-crash.md)