## Basic information Project name: Eclipse OpenJ9 Project id: technology.openj9 ## What are the affected versions? Confirmed present, unchanged, on the current `master` branch tip (checked 2026-09-11) 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`. The only commit touching `RawTypeConvert.hpp` since the file's introduction is a clang-format reformatting pass (`4e42110765c5b90fea977298555881417ceae882`, 2026-02-25) -- confirmed purely cosmetic by direct diff of the vector-decode logic before and after: the unbounded `for (uint32_t i = 0; i < size; ++i)` loop and the unchecked `values.reserve(size)` call are byte-for-byte the same statements, just reformatted. This is the same root-cause defect, in the same file, already established for work item #943; this finding reaches it through a different message type and call path (below). ## Details of the issue Vulnerable source, pinned to the exact commit this PoC was tested against: - Unbounded loop, no bound check against the message's actual size: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/RawTypeConvert.hpp#L165-L179 - `DataDescriptor::getNextDescriptor()`, the unchecked pointer advance used by the loop above: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/Message.hpp#L198-L201 - `MessageType` enum, confirming `getUnloadedClassRangesAndCHTable` = ordinal 7: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/MessageTypes.hpp#L31-L40 - The new decode entry point, `ServerStream::read<T...>()` (distinct from `readCompileRequest()`, the entry point used by #940/ #941/ #943): https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/ServerStream.hpp#L116-L135 - `ServerStream::readCompileRequest()`, shown for direct comparison: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/ServerStream.hpp#L158-L184 - The unconditional `write()`/`read()` exchange, first thing done for any brand-new client session: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/control/JITServerCompilationThread.cpp#L745-L761 - `ClientSessionData::cachesAreCleared()`, returning `_requestUnloadedClasses`: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/runtime/JITClientSession.hpp#L432 - `_requestUnloadedClasses(true)` in the `ClientSessionData` constructor -- `true` for every brand-new session, keyed by the attacker-chosen `clientId`: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/runtime/JITClientSession.cpp#L42-L54 `ServerStream.hpp` defines two distinct server-side receive entry points. `readCompileRequest()` is the entry point already exercised by #940/ #941/ #943 and only dispatches `compilationRequest` and `AOTCacheMap_request`, both already reported. `read<T...>()` is a second, independent decode path the server uses to receive replies to its own outbound queries mid-processing. It does not repeat the `fullVersion` compatibility check (already satisfied once, on the connection's first message) and only requires the reply's own `_type` field to match whatever type the server is currently expecting -- a value fully controlled by the sender. `CompilationInfoPerThreadRemote::processCompilationRequest()`, called immediately after `readCompileRequest()` returns `MessageType::compilationRequest`, contains a double-checked-locking block: ```cpp if (clientSession->cachesAreCleared()) { OMR::CriticalSection cs(clientSession->getCacheInitMonitor()); if (clientSession->cachesAreCleared()) { stream->write(JITServer::MessageType::getUnloadedClassRangesAndCHTable, compInfo->getPersistentInfo()->getServerUID()); auto response = stream->read<std::vector<TR_AddressRange>, int32_t, std::string, std::vector<J9Method*>>(); ... } } ``` `cachesAreCleared()` returns `_requestUnloadedClasses`, initialized `true` in the `ClientSessionData` constructor for every brand-new session. `clientId` (field 0 of the `compilationRequest` tuple) is entirely attacker-chosen, with no cryptographic or credential check of any kind. So the very first `compilationRequest` ever sent for any given `clientId` unconditionally triggers this `write()`/`read()` exchange, before any real compilation work happens. Reaching the vulnerable state requires only: (1) one well-formed, minimal `compilationRequest` message, `fullVersion() == 0` (the same pre-auth bypass already established for #940/ #941/ #943), any `clientId` the server has not seen before; (2) receiving the server's `getUnloadedClassRangesAndCHTable` query; (3) sending a crafted reply, `type=7`, field 0 (`std::vector<TR_AddressRange>`) crafted as `DataType::VECTOR` with a nested `UINT32` size descriptor declaring 5,000,000 elements, followed by exactly one real, well-formed element. No authentication, session token, or prior legitimate compile ever occurs. `TR_AddressRange` is trivially copyable, so its elements decode via the generic "trivially copyable" `RawTypeConvert<T>` specialization (`DataType::OBJECT`), which never checks the descriptor's declared payload size against `sizeof(T)` -- only the descriptor's own attacker-controlled `_size` field governs how far `getNextDescriptor()` advances. The exact real struct size is therefore immaterial to reproducing the crash. ## Relationship to work items #940 / #941 / #943 Same underlying defect as #943 (the unbounded loop in `RawTypeConvert<std::vector<T>>::onRecv()`), but a genuinely different trigger. #943: message type `compilationRequest` (8), decoded via `ServerStream::readCompileRequest()`, target field 8 (`std::vector<TR_OpaqueClassBlock*>`) of the 26-field `CompilationRequest` tuple, crash-stack caller `ServerStream::readCompileRequest<...>`. This finding: message type `getUnloadedClassRangesAndCHTable` (7), decoded via `ServerStream::read<T...>()`, target field 0 (`std::vector<TR_AddressRange>`) of a new 4-field reply tuple, crash-stack caller `CompilationInfoPerThreadRemote::processCompilationRequest`. The crash stack trace's innermost frame is a byte-exact match for the predicted template instantiation of this finding's specific tuple (`getArgsRaw<std::vector<TR_AddressRange>, int32_t, std::string, std::vector<J9Method*>>`), called from `processCompilationRequest` -- not `readCompileRequest`, which is what #940/ #941/ #943 all show instead. This is direct, register-and-symbol-level proof of a distinct code path, not a re-trigger of an already-reported one. #941 is a single-shot OOB read via a different field entirely (`AOTCacheMap_request`'s string field); #940 is an unrelated integer-overflow infinite loop in buffer-capacity growth, not this loop at all. ## Impact `jitserver` is a shared, long-running network service -- IBM's own documented JITServer use case is one instance serving compilation requests for multiple client JVMs at once. A single crafted 88-byte reply message from an unauthenticated network peer, with one prerequisite well-formed message and no credentials, crashes the whole `jitserver` process with SIGSEGV, taking down compilation service for every client currently attached to that instance, not just the connecting peer. The crash is deterministic and repeatable at will by anyone who can reach the JITServer TCP port (default 38400). This is a pre-auth remote denial-of-service; no attempt was made to read, print, or characterize any bytes from the out-of-bounds region, and no code-execution path is claimed here or in the three 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 (two well-formed/crafted messages on one TCP connection, no timing or 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 sibling findings in this family. ## Steps to reproduce 1. Prerequisites: Docker installed and running, outbound network access to pull the image (or the image already cached locally), two free host ports for two containers, Python 3 for the test-client scripts (`send_baseline.py`, `send_crash_poc.py`, attached). On Windows/Git Bash, set `MSYS_NO_PATHCONV=1` before `docker run` so the container's absolute binary path is not mangled by MSYS path translation. 2. Pull/confirm the official image and start two fresh containers (one for the negative control, one for the crash): `docker run -d --name jitserver-chtable-shot-b -p 38421:38400 ibm-semeru-runtimes:open-21.0.10_7.1-jdk /opt/java/openjdk/bin/jitserver` (and a second, `-c`, on a second port). Confirm both are ready via `docker logs`. {width="900" height="576"} 2. Run `send_baseline.py` against the first container (field 0 of the `getUnloadedClassRangesAndCHTable` reply = `EMPTY_VECTOR`, well-formed). The server replies normally and the process stays alive (`ExitCode=0`, same PID). {width="900" height="576"} 3. Run `send_crash_poc.py` against the second container (field 0 declares element count = 5,000,000, every other field left well-formed). The connection closes with no reply (`recv()` returns 0 bytes = clean EOF). {width="900" height="576"} 4. `docker logs` on the second container shows the crash: real SIGSEGV, register `R15 = 0x004C4B40 = 5,000,000` -- the injected count, live in a register at fault time -- and `RSI = 0x04C4B400 = 80,000,000 = 5,000,000 x 16`, consistent with a `size * sizeof(TR_AddressRange)`-shaped computation. {width="900" height="576"} 5. Same log, stack trace: innermost frame is `getArgsRaw<..., std::vector<TR_AddressRange>, ...>`, called from `processCompilationRequest` -- the distinct call path proving this is a genuinely new code path versus #940/ #941/ #943. {width="900" height="576"} 6. `docker ps -a` / `docker inspect` confirm the container process exited (`Exited (255)`, `Running=false`, `OOMKilled=false`) at the same moment as the crash -- a real process death, not a hang. {width="900" height="576"} Reproduction determinism: 1/1 attempt crashed the crash PoC (reproduced twice independently -- once for the original evidence capture, once fresh for these screenshots, both with matching register signatures); 1/1 attempt on the well-formed baseline did not crash. Full write-up, both PoC scripts, and the raw `docker logs` crash dumps (original and freshly re-captured) are attached below. ## Do you know any mitigations of the issue? Same fix direction as the already-reported sibling findings: bound the loop count in `RawTypeConvert<std::vector<T>>::onRecv()` against the message's actual remaining declared size before iterating, in addition to the existing top-level buffer-size checks, since those never recurse into nested vector decoding. Because this same unbounded-loop pattern is reachable from at least two independent message types/tuples now (`compilationRequest` field 8, and this reply's field 0), a single fix at the shared `RawTypeConvert<std::vector<T>>::onRecv()` site closes all currently-known instances at once, rather than patching each call site individually. [send_crash_poc.py](/uploads/835a6458cc9bf52354906a45a3c91c21/send_crash_poc.py) [send_baseline.py](/uploads/ffae7f713cdcc35cb99d7b39d555d869/send_baseline.py) [crash_log_full.txt](/uploads/1515bfb48ec9ca0c56e8afa5255bef4c/crash_log_full.txt) [POC-openj9-jitserver-chtable-reply-vecwalk-crash.md](/uploads/de3a7804cc693bf0ccce638fd6cc3df9/POC-openj9-jitserver-chtable-reply-vecwalk-crash.md)