Ohler55

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** Oj is a JSON parser and Object marshaller for Ruby. The `Oj.load` function is susceptible to heap corruption when processing a JSON string exceeding 2 GB. An integer overflow occurs within the `buf append string()` function (located in `buf.h:61`), where the string length is converted to a large negative `size t`. This causes `memcpy` to copy an excessive amount of data out of bounds, leading to process crashes and corruption of adjacent heap memory. The issue is triggered during escape sequence handling in the `read escaped str()` function, where the remaining string length is incorrectly computed as an `int`. **Recommendations** Update Oj to version 3.17.2 or later.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** When operating in object mode, the `Oj.dump` function is susceptible to a heap buffer overflow during the serialization of Exception objects if a large `:indent` value is used. The issue occurs because the serializer allocates a buffer based on the object's attributes but fails to account for the additional bytes required for indentation on each write. For example, using `indent: 5000` can cause the accumulation of indent strings to exceed the allocated heap memory, leading to memory corruption. This process involves the `fill indent()` function, which is called repeatedly by `dump obj attrs()` when processing attributes of an Exception object. **Recommendations** Update Oj to version 3.17.2 or later. Avoid using extreme values for the `:indent` parameter and do not allow users to specify unlimited indentation sizes when dumping Ruby data.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** Oj::Doc iterators (`each value`, `each child`, `each leaf`) are subject to a heap use-after-free. This occurs when a Ruby block yielded during iteration calls `doc.close` or `d.close`, causing the document's heap memory to be freed while the C iterator is still active. Upon returning control from the block, the iterator attempts to read from the freed memory region, making the use-after-free accessible from pure Ruby. **Recommendations** Update Oj to version 3.17.2 or later.

**Name of the Vulnerable Software and Affected Versions** oj gem (affected versions not specified) **Description** A heap use-after-free occurs in `Oj::Parser#parse` when a SAJ/SAJ2 callback mutates the input JSON string during the parsing process. The C engine maintains a raw pointer to the Ruby string's internal buffer. If a callback, such as `hash start()`, resizes the string (for example, via `String#replace`), Ruby reallocates the buffer and frees the original memory. This leaves the C parser with a dangling pointer, leading to a use-after-free when the next character is read. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** A heap use-after-free occurs when disabling `symbol keys` on a reused `Oj::Parser` instance. When the `symbol keys` setting is changed from `true` to `false`, the `opt symbol keys set` function frees the internal key cache using `cache free` but fails to clear the pointer. Consequently, the subsequent call to the `parse` function attempts to read from the freed cache via `cache intern`, leading to a use-after-free condition. **Recommendations** Update to version 3.17.2 or later.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** When operating in usual mode with `create id` enabled, the `Oj::Parser#parse` function is susceptible to heap corruption. This occurs when a JSON object key is exactly 65,535 bytes long, leading to an integer truncation within the `form attr()` function. The truncation converts the length to -1 before it is passed to `memcpy`, causing the system to copy `SIZE MAX` bytes. This results in heap memory corruption and causes the process to crash. **Recommendations** Update to version 3.17.2 or later. As a temporary workaround, avoid using the `Oj::Parser#parse` function in usual mode with `create id` enabled when processing untrusted JSON input.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** Oj::Parser in usual mode fails to mark `array class` and `hash class` references during garbage collection (GC), resulting in a Use-After-Free condition. If the GC executes after the class is assigned but before a parse operation, the class object is reclaimed, leaving the parser with a dangling VALUE. A subsequent call to the `parse()` function dereferences this freed object, leading to a segmentation fault. This occurs because the `parser mark()` function in `ext/oj/parser.c` does not pass `array class` to `rb gc mark()`, causing the GC to collect the referenced class. The crash specifically happens when `close array class()` calls `rb funcallv()` on the collected class VALUE. **Recommendations** Update to version 3.17.2.

**Name of the Vulnerable Software and Affected Versions** Oj versions prior to 3.17.2 **Description** Oj is a JSON parser and Object marshaller for Ruby. A Use-After-Free issue exists when using the `Oj::Parser` in SAJ mode. The parser fails to protect cached object keys of 35 bytes or more from garbage collection. If a Ruby callback triggers garbage collection within the `hash end` function, the key string may be reclaimed while the C parser still maintains a pointer to it. Subsequent access to this freed string value can lead to a segmentation fault, potentially allowing control over the freed memory content. **Recommendations** Update Oj to version 3.17.2 or later.

**Name of the Vulnerable Software and Affected Versions** Optica versions prior to 0.10.2 **Description** A remote code execution issue in Optica allows unauthenticated attackers to execute arbitrary code via specially crafted JSON payloads. This can lead to remote code execution on the attacked system running Optica. **Recommendations** For versions prior to 0.10.2, update to version 0.10.2 or later, where the call to the function `oj.load` was changed to `oj.safe load` to resolve the issue.