From b6610ebb3fdb53c696bb105e2b2aad38b2f25c59 Mon Sep 17 00:00:00 2001
From: Al Snow <43523+jasnow@users.noreply.github.com>
Date: Tue, 23 Jun 2026 11:58:51 -0400
Subject: [PATCH] And 4 more oj gem advisories

---
 gems/oj/CVE-2026-54900.yml | 29 +++++++++++++++++++++++++++++
 gems/oj/CVE-2026-54901.yml | 28 ++++++++++++++++++++++++++++
 gems/oj/CVE-2026-54902.yml | 30 ++++++++++++++++++++++++++++++
 gems/oj/CVE-2026-54903.yml | 28 ++++++++++++++++++++++++++++
 4 files changed, 115 insertions(+)
 create mode 100644 gems/oj/CVE-2026-54900.yml
 create mode 100644 gems/oj/CVE-2026-54901.yml
 create mode 100644 gems/oj/CVE-2026-54902.yml
 create mode 100644 gems/oj/CVE-2026-54903.yml

diff --git a/gems/oj/CVE-2026-54900.yml b/gems/oj/CVE-2026-54900.yml
new file mode 100644
index 0000000000..f82fbf459e
--- /dev/null
+++ b/gems/oj/CVE-2026-54900.yml
@@ -0,0 +1,29 @@
+---
+gem: oj
+cve: 2026-54900
+ghsa: 9cv6-qcjw-4grx
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54900
+title: Oj - Negative-Size memcpy in 'Oj::Parser' create_id Attribute Handling
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Oj::Parser#parse` in usual mode with `create_id` enabled is vulnerable
+  to heap corruption via a negative-size `memcpy`. When a JSON object key
+  is exactly 65,535 bytes long, an integer truncation in `form_attr`
+  (`usual.c:63`) converts the length to `-1` before passing it to `memcpy`.
+  This causes `memcpy` to copy `SIZE_MAX` bytes (interpreted as a huge
+  `size_t`), corrupting heap memory and crashing the process.
+cvss_v4: 8.7
+patched_versions:
+  - ">= 3.17.3"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54900
+    - https://rubygems.org/gems/oj/versions/3.17.3
+    - https://github.com/ohler55/oj/blob/master/CHANGELOG.md#3173---2026-06-04
+    - https://github.com/ohler55/oj/pull/1015
+    - https://github.com/ohler55/oj/security/advisories/GHSA-9cv6-qcjw-4grx
+    - https://github.com/advisories/GHSA-9cv6-qcjw-4grx
+notes: |
+  - CVE is reserved, but published so no cvss_v2 or cvss_v3 values.
diff --git a/gems/oj/CVE-2026-54901.yml b/gems/oj/CVE-2026-54901.yml
new file mode 100644
index 0000000000..0b0d106e58
--- /dev/null
+++ b/gems/oj/CVE-2026-54901.yml
@@ -0,0 +1,28 @@
+---
+gem: oj
+cve: 2026-54901
+ghsa: vwm4-62gf-x745
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54901
+title: Oj-  Use-After-Free in 'Oj::Parser' array_class/hash_class GC Marking
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Oj::Parser` in usual mode does not mark `array_class` and `hash_class`
+  references during garbage collection. If GC runs after the class is
+  assigned but before a parse, the class object is reclaimed, leaving
+  the parser holding a dangling VALUE. The subsequent `parse` call
+  dereferences the freed object, producing a segfault.
+cvss_v4: 8.7
+patched_versions:
+  - ">= 3.17.3"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54901
+    - https://rubygems.org/gems/oj/versions/3.17.3
+    - https://github.com/ohler55/oj/blob/master/CHANGELOG.md#3173---2026-06-04
+    - https://github.com/ohler55/oj/pull/1015
+    - https://github.com/ohler55/oj/security/advisories/GHSA-vwm4-62gf-x745
+    - https://github.com/advisories/GHSA-vwm4-62gf-x745
+notes: |
+  - CVE is reserved, but published so no cvss_v2 or cvss_v3 values.
diff --git a/gems/oj/CVE-2026-54902.yml b/gems/oj/CVE-2026-54902.yml
new file mode 100644
index 0000000000..0681cc3886
--- /dev/null
+++ b/gems/oj/CVE-2026-54902.yml
@@ -0,0 +1,30 @@
+---
+gem: oj
+cve: 2026-54902
+ghsa: m578-w5vf-rfcm
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54902
+title: Oj - Use-After-Free in 'Oj::Parser' SAJ Long Key Callback
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Oj::Parser` in SAJ mode does not protect cached object keys (≥ 35 bytes)
+  from garbage collection. A Ruby callback that triggers GC inside
+  `hash_end` can cause the key string to be reclaimed while the C
+  parser still holds a pointer to it. The subsequent access to the
+  freed string VALUE results in a segfault, confirmed by an
+  RIP pointing to address `0x4242` (a canary-style pattern suggesting
+  control over the freed memory's content).
+cvss_v4: 8.7
+patched_versions:
+  - ">= 3.17.3"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54902
+    - https://rubygems.org/gems/oj/versions/3.17.3
+    - https://github.com/ohler55/oj/blob/master/CHANGELOG.md#3173---2026-06-04
+    - https://github.com/ohler55/oj/pull/1015
+    - https://github.com/ohler55/oj/security/advisories/GHSA-m578-w5vf-rfcm
+    - https://github.com/advisories/GHSA-m578-w5vf-rfcm
+notes: |
+  - CVE is reserved, but published so no cvss_v2 or cvss_v3 values.
diff --git a/gems/oj/CVE-2026-54903.yml b/gems/oj/CVE-2026-54903.yml
new file mode 100644
index 0000000000..a128fa0be4
--- /dev/null
+++ b/gems/oj/CVE-2026-54903.yml
@@ -0,0 +1,28 @@
+---
+gem: oj
+cve: 2026-54903
+ghsa: 475m-ph3x-64gp
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54903
+title: Oj - Integer Overflow in Oj.load 2GB String Handling
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Oj.load` is vulnerable to heap corruption when parsing a JSON string
+  longer than 2 GB. An integer overflow in `buf_append_string`
+  (`buf.h:61`) converts the string length to a large negative `size_t`,
+  causing `memcpy` to copy an astronomically large amount of data out of
+  bounds. This crashes the process and can corrupt adjacent heap memory.
+cvss_v4: 8.7
+patched_versions:
+  - ">= 3.17.3"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54903
+    - https://rubygems.org/gems/oj/versions/3.17.3
+    - https://github.com/ohler55/oj/blob/master/CHANGELOG.md#3173---2026-06-04
+    - https://github.com/ohler55/oj/pull/1015
+    - https://github.com/ohler55/oj/security/advisories/GHSA-475m-ph3x-64gp
+    - https://github.com/advisories/GHSA-475m-ph3x-64gp
+notes: |
+  - CVE is reserved, but published so no cvss_v2 or cvss_v3 values.