## Basic information Project name: Eclipse OpenJ9 Project id: technology.openj9 ## What are the affected versions? Confirmed present at commit `f0754f410244ad2c42b07c5fe76983a3c7b61e87` (OpenJ9 0.57.0, bundled in `ibm-semeru-runtimes:open-21.0.10_7.1-jdk`, the image dynamically tested below) via a fresh, direct fetch of the raw source pinned to that exact commit SHA (not a branch/tag). The same field (`_tmpInterfaces`, index 5) retains the identical type, position, and missing-bounds-check defect at tag `openj9-0.62.0` -- that later tag's `ClassInfoTuple` differs only in its *tail* fields (indices 24-26: the tested commit has `_defaultValueSlotAddress`/hash-string/`_nullRestrictedArrayClass`, while `openj9-0.62.0` has hash-string/`_nullRestrictedArrayClass`/`_arity`), well past element 5 and irrelevant to this finding. Same affected version range as the four already-reported sibling findings in this family (work items #940, #941, #943, #944). **Correction note on sourcing:** an earlier internal draft of this write-up cited the `ClassInfoTuple` field table against a local source dump that was later found to have actually been pulled from tag `openj9-0.62.0` rather than the exact tested commit. The table in this report has been re-derived directly from the tested commit's raw GitHub source (permalink below), superseding that earlier draft. This correction is purely about which exact commit a citation points to -- it does not affect the crash finding itself, since element 5's type/position is identical in both versions. ## Details of the issue This is the same underlying defect already reported in #940/#941/#943/#944 (an attacker-controlled, unbounded element count in `RawTypeConvert<std::vector<T>>::onRecv()`, `runtime/compiler/net/RawTypeConvert.hpp`), but reached through a **third distinct call path**: this time via a vector field nested **inside** a nested `std::tuple`, rather than directly at the top level of the `compilationRequest` message (as in #943) or via a server-initiated reply message (as in #944). `JITServerHelpers::ClassInfoTuple` (`runtime/compiler/control/JITServerHelpers.hpp`) is a 27-element `std::tuple` carried as field 10 of `CompilationRequest`: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/control/JITServerHelpers.hpp#L65-L94 `CompilationRequest`'s own tuple layout, confirming field 10 is `ClassInfoTuple`: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/control/JITServerCompilationThread.hpp `ClassInfoTuple` carries three vector-typed fields (index 5 `_tmpInterfaces`, 6 `_methodTracingInfo`, 21 `_origROMMethods`) and three string-typed fields (0, 22, 25), every one decoded via the exact same unchecked templates already proven vulnerable at the top level. This finding targets element 5, `_tmpInterfaces` (`std::vector<TR_OpaqueClassBlock*>`). Reaching this nested vector requires the message parser to first walk into the nested-tuple decode specialization, which does **not** execute at all in the #943 reproduction: ```cpp template<typename... T> struct RawTypeConvert<const std::tuple<T...> > { static inline std::tuple<T...> onRecv(Message::DataDescriptor *desc) { TR_ASSERT(desc->getDataType() == Message::DataDescriptor::DataType::TUPLE, "onRecv type missmatch TUPLE"); return TupleTypeConvert<0, T...>::onRecvImpl(static_cast<Message::DataDescriptor *>(desc->getDataStart())); } }; template<size_t n, typename Arg1, typename... Args> struct TupleTypeConvert { static inline std::tuple<Arg1, Args...> onRecvImpl(Message::DataDescriptor *desc) { return std::tuple_cat(TupleTypeConvert<n, Arg1>::onRecvImpl(desc), TupleTypeConvert<n + 1, Args...>::onRecvImpl(desc->getNextDescriptor())); } }; ``` https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/RawTypeConvert.hpp When the recursion reaches element 5, `TupleTypeConvert<5, std::vector<TR_OpaqueClassBlock*>>::onRecvImpl()` calls the same vulnerable specialization already reported: ```cpp template <typename T> struct RawTypeConvert<T, typename std::enable_if<std::is_same<T, std::vector<typename T::value_type>>::value>::type> { static inline T onRecv(Message::DataDescriptor *desc) { Message::DataDescriptor *sizeDesc = static_cast<Message::DataDescriptor *>(desc->getDataStart()); uint32_t size = RawTypeConvert<uint32_t>::onRecv(sizeDesc); // attacker-controlled, unchecked std::vector<typename T::value_type> values; values.reserve(size); auto curDesc = sizeDesc->getNextDescriptor(); for (uint32_t i = 0; i < size; ++i) // no check against remaining buffer size { values.push_back(RawTypeConvert<typename T::value_type>::onRecv(curDesc)); curDesc = curDesc->getNextDescriptor(); // pure pointer arithmetic, no bounds check } return values; } }; ``` `DataDescriptor::getNextDescriptor()` (`runtime/compiler/net/Message.hpp`) remains pure pointer arithmetic with no bounds check, identical to the four sibling findings. Reached via `MessageType::compilationRequest` (ordinal 8), the first message read on a fresh connection, before any auth/version check (`fullVersion=0` bypass, same as all four sibling findings). ### The crafted message A well-formed 26-field `compilationRequest`, `numDataPoints=26`, every field well-formed except field 10 (`ClassInfoTuple`), whose own 27 elements are all well-formed except element 5 (`_tmpInterfaces`): `DataType::VECTOR` with a nested `UINT32` size descriptor declaring **6,200,000** elements, followed by exactly one real, well-formed element. Fields 8, 9 (the already-reported top-level vector fields from #943) and field 23 (`std::vector<ClassInfoTuple>`, also already reported) are all left well-formed `EMPTY_VECTOR` in this PoC, isolating the reproduction strictly to the newly-targeted nested field. Total message size: 956 bytes. ### Crash evidence Real, officially-built `jitserver` binary (`ibm-semeru-runtimes:open-21.0.10_7.1-jdk`), Docker container `jitserver-classinfo-nested2`, port 38402. Before: `pgrep -a -f jitserver` -> `1 /opt/java/openjdk/bin/jitserver`, container `Status=running`. Payload sent (956 bytes) -> `recv()` returned 0 bytes (clean EOF, server died before replying). After: container `Status=exited Running=false ExitCode=255`. `docker logs` crash dump: `Type=Segmentation error`, `Signal_Number=0000000b` (SIGSEGV). **`R13 = 0x00000000005E9AC0 = 6,200,000` decimal**, live in a register at fault time -- the exact attacker-declared count for `ClassInfoTuple` element 5, tying the fault unambiguously to this specific nested field. `RBP = 0x000000000001A8C6 = 108,742` decimal, a partial-progress value well short of the full 6,200,000-iteration budget -- confirming the crash happened after many out-of-bounds hops (the same "loop counter mid-walk" signature already established for #943/#944), not on the first one. `RAX = 0xCAFEDADA` is a fixed sentinel value also seen identically in #943's dump, unrelated to this PoC's payload. **Stack trace confirms a genuinely distinct code path from #943**: the crash's innermost two frames are `JITServer::TupleTypeConvert<...>::onRecvImpl()` (demangled: `n=3`, argument-type pack matching `ClassInfoTuple`'s own element types starting at index 3 -- `_numDimensions, _parentClass, _tmpInterfaces, _methodTracingInfo, _classHasFinalFields, ...`), then `TupleTypeConvert<0, std::string, J9Method*, ...>::onRecvImpl()` -- a call chain that **only exists when decoding a field-10-shaped nested tuple**, categorically absent from #943's crash dump, whose innermost frames are `JITServer::GetArgsRaw<...>` directly with no `TupleTypeConvert` frame anywhere. Above these nested-tuple frames, the trace continues through the same outer chain as all four sibling findings: `GetArgsRaw<...>` -> `getArgsRaw<...>` -> `ServerStream::readCompileRequest<...>` -> `CompilationInfoPerThreadRemote::processEntry` -> `CompilationInfoPerThread::processEntries/run` -> `protectedCompilationThreadProc` -> `omrsig_protect` -> `compilationThreadProc` -> `thread_wrapper` -> `__clone`. ### Baseline / negative control A fresh container sent a message identical in every field, but with `ClassInfoTuple` entirely well-formed (all 27 elements, including its own three vector fields, encoded as well-formed `EMPTY_VECTOR`/zero fillers). Result: `recv()` returned a normal 32-byte well-formed server reply (`type=7`, `getUnloadedClassRangesAndCHTable`) -- the server fully decoded all 27 `ClassInfoTuple` elements without error and proceeded into genuine request handling. After: `pgrep` still shows the same PID, container still `running`. This isolates the fault strictly to the oversized declared count in element 5, not to anything else about the message shape or reaching/decoding `ClassInfoTuple` at all. ## Relationship to work items #940 / #941 / #943 / #944 | | #943 | #944 | This finding | |---|---|---|---| | Vulnerable function | `RawTypeConvert<std::vector<T>>::onRecv()` | same | same | | Reached via | `compilationRequest` field 8 (top-level) | `getUnloadedClassRangesAndCHTable` reply, field 0 | `compilationRequest` field 10 (`ClassInfoTuple`), **element 5, one level nested inside a `std::tuple`** | | Decode call chain | `GetArgsRaw<...>` directly | `ServerStream::read<T...>()` (separate entry point) | `GetArgsRaw<...>` -> `RawTypeConvert<const std::tuple<T...>>::onRecv()` -> `TupleTypeConvert<n,...>::onRecvImpl()` -> `RawTypeConvert<vector<T>>::onRecv()` -- **two additional recursion frames absent from #943/#944** | | Stack trace signature | No `TupleTypeConvert` frame | No `TupleTypeConvert` frame | `TupleTypeConvert<3,...>` and `TupleTypeConvert<0,...>` frames present -- unique to this finding | | Attacker-declared count (register) | R14=5,000,000 | R15=5,000,000 | **R13=6,200,000** (deliberately a different value, to unambiguously tie the fault to this field) | This proves the missing-bounds-check defect is not confined to vector fields enumerated directly in the outer message's own top-level tuple, or to server-initiated reply messages: it reproduces identically for a vector field nested one level deeper inside a nested tuple, via a call path that is structurally, symbolically, and register-evidence distinct from all three prior findings. ## 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 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 instance. The crash is deterministic and repeatable: 1/1 attempt with the malformed nested field crashed; 1/1 attempt on the well-formed baseline did not. 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 four 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 (one well-formed message, no timing/race requirement, no precondition outside the attacker's own actions), no privileges or user interaction required, no confidentiality/integrity impact demonstrated, high availability impact (total, repeatable loss of the JITServer process). Same severity class as the already-reported sibling findings #943/#944 (both iterative unbounded-walk crashes, as opposed to #941's single-shot OOB read). ## Steps to reproduce Prerequisites: Docker installed and running, outbound network access to pull the image, port 38402 free, 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-classinfo-nested2 -p 38402:38400 ibm-semeru-runtimes:open-21.0.10_7.1-jdk /opt/java/openjdk/bin/jitserver`. Confirm ready via `docker logs jitserver-classinfo-nested2` (`JITServer is ready to accept incoming requests`). 2. Run `send_baseline.py` (all fields well-formed, including all 27 `ClassInfoTuple` elements). Server replies normally (32-byte well-formed reply), process stays alive. 3. Against a fresh container, run `send_crash_poc.py` (`ClassInfoTuple` element 5 declares count=6,200,000). Connection closes with no reply (`recv()` returns 0 bytes). 4. `docker logs` on the second container shows the crash: SIGSEGV, `R13=0x005E9AC0=6,200,000` live, stack trace containing `JITServer::TupleTypeConvert<...>::onRecvImpl()` frames. 5. `docker inspect`/`docker ps -a` confirm the container exited (255) at the same moment as the crash. Full write-up, both PoC scripts, and the raw `docker logs`/before-after process-check output are attached below. ## Do you know any mitigations of the issue? Same fix direction as the four sibling findings: bound the loop count in `RawTypeConvert<std::vector<T>>::onRecv()` against the message's actual remaining declared size before iterating, at the single shared template definition, so the fix covers every call site -- top-level fields, nested-tuple fields, and reply-message fields alike -- at once. Since this finding demonstrates the defect generalizes to vector fields nested inside nested tuples (and, per the source-level analysis in this report, very likely to the four other similarly-typed fields within `ClassInfoTuple` itself, and to `std::vector<ClassInfoTuple>` at field 23), a single fix at the shared template site is strongly preferable to patching individual call sites. --- **Attachments:** - [POC-openj9-jitserver-classinfo-nested-vector-crash.md](/uploads/f77c09c99a1059e09874c54b2d5bc62d/POC-openj9-jitserver-classinfo-nested-vector-crash.md) - [send_crash_poc.py](/uploads/4081e1139da03798e786784efeac413b/send_crash_poc.py) - [send_baseline.py](/uploads/2c782935f9e895bfd241ca929907e402/send_baseline.py) - [baseline_output.txt](/uploads/f3bd33bf47ebf179e220f861639e8a8d/baseline_output.txt) - [crash_output.txt](/uploads/f7537c49cedc22b5cb9189d09879d792/crash_output.txt) - [crash_log_full.txt](/uploads/5f9b135b36a474bb5f8d1cf9ab2b160a/crash_log_full.txt) - [JITServerHelpers.hpp.actual_commit](/uploads/525f1b77495b750408a7afa334e77dec/JITServerHelpers.hpp.actual_commit)