Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Oj::Doc iterators (eachvalue, eachchild, eachleaf) are vulnerable to a heap use-after-free. When a Ruby block yielded during iteration calls doc.close or d.close, the document's heap memory is freed while the C iterator is still running. When control returns from the block, the iterator reads from the freed region, producing a use-after-free accessible from pure Ruby. Version - Software: oj gem - Affected: all versions with ext/oj/fast.c - Latest tested: 3.17.1 (confirmed present) Details The iterators in ext/oj/fast.c follow the pattern: rbyield can invoke arbitrary Ruby code, including calling close() on the Doc or any child node, which calls rubysizedxfree on the backing buffer. On return, the C code reads cur-next from the freed region. All three iterators are affected. ASAN report (eachchild variant): All three iterators trigger the same freed region (fd shadow bytes): Reproduce
Recommended action: Upgrade to 3.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Oj::Doc#eachchild, when invoked recursively over a deeply nested JSON document, overflows a fixed-size stack buffer and aborts the process. This is a denial of service reachable from untrusted JSON. Details Two-step chain in ext/oj/fast.c: 1. doceachchild (~line 1501) increments doc-where past the wherepath[MAXSTACK = 100] array with no bounds check, and never restores it (doc-where-- is missing). Calling eachchild recursively from inside the yield block therefore drives doc-where beyond the array. 2. On the next entry (~line 1478) the function copies the path into a stack-local buffer: When the previous recursive call left doc-where past wherepath[100], wlen exceeds MAXSTACK and the memcpy overflows savepath on the C stack. The Oj::Doc parser imposes no JSON nesting-depth limit (it relies on a C-stack pressure check), so deeply nested attacker input reaches this path. Proof of Concept Recursion depth <= 99 iterates normally; depth = 101 aborts. lldb backtrace on the affected…
Recommended action: Upgrade to 3.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Oj.load in :object mode reads uninitialized stack memory (and, for long keys, reads out of bounds) when parsing a JSON object whose key is 254 bytes or longer. The interned bytes can surface to the caller, disclosing process stack memory. Details In ext/oj/intern.c, formattr() handles the long-key path by allocating a heap buffer b, populating it with the attribute name, and then freeing it — but it passed the uninitialized stack buffer buf (not b) to rbintern3(): rbintern3 therefore reads len + 1 bytes of uninitialized stack memory. When the key length is = 256, it also reads out of bounds past the 256-byte buf (CWE-125). The resulting bytes are interned and can reach the caller via the produced Symbol or via the EncodingError message raised on invalid UTF-8, leaking process stack contents. This is the same defect previously fixed in ext/oj/usual.c; intern.c held a duplicated copy of formattr that was missed. Proof of Concept On affected versions this raises an EncodingError…
Recommended action: Upgrade to 3.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Disabling symbolkeys on a reused Oj::Parser instance triggers a heap use-after-free. When symbolkeys is toggled from true to false, optsymbolkeysset frees the internal key cache (cachefree) but does not clear the pointer. The next parse call reads from the freed cache via cacheintern, producing a use-after-free. Version - Software: oj gem - Affected: all versions with ext/oj/usual.c - Latest tested: 3.17.1 (confirmed present) Details ext/oj/usual.c, optsymbolkeysset: On the next parse call, cachekey → cacheintern reads from d-keycache which now points to freed memory. ASAN report: Reproduce
Recommended action: Upgrade to 3.17.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.