CVE-2024-3933 is a medium severity memory access flaw in Eclipse OpenJ9, scored 5.3 by NVD. It affects releases after 0.13.0 and before 0.44.0 on IBM Z when the JVM runs with the concurrentScavenge option. Upgrade to 0.44.0 or later.
What's affected
Per the record, Eclipse OpenJ9 release versions prior to 0.44.0 and after 0.13.0 are affected, so the fixed release is 0.44.0. The flaw only applies in a narrow case. The JVM must run with the option -Xgc:concurrentScavenge on the IBM Z platform with hardware and software support for guarded storage.
In that setup, the code generated for System.arraycopy could use a wrong length for a buffer while a Concurrent Scavenge garbage collection cycle is active and the source and destination regions overlap. The record links the fixing change in the Eclipse OMR project and an Eclipse security issue.
The vector is local with high attack complexity. The KEV flag is false and no exploitation is reported.
The NVD record is dated 2024-05-27 and carries the vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L, a score of 5.3 (Medium). Weakness class: CWE-125, CWE-787, CWE-805.
How to check if you're exposed
First decide whether you are in the narrow case at all. Three conditions must hold: the platform is IBM Z with guarded storage support, the runtime is OpenJ9 between 0.13.0 and 0.44.0, and the JVM runs with concurrentScavenge enabled.
Check the runtime version.
java -version
OpenJ9 builds report their release in the version output. Then look at the launch options in service files, container entry points and application server configuration for the garbage collection flag.
grep -r "concurrentScavenge" /etc /opt 2>/dev/null
If any condition is false, the described scenario does not apply, though you should still plan to move to a current release.
What to do now
- Identify JVMs that run on IBM Z with an OpenJ9 build between 0.13.0 and 0.44.0.
- Upgrade those runtimes to OpenJ9 0.44.0 or later.
- Until you can upgrade, consider removing the concurrentScavenge option on affected hosts, and test the performance effect before rollout.
- Rebuild container images and application bundles that ship their own OpenJ9 runtime.
- Add the runtime version to your inventory so that future JVM advisories are easy to match.
Why it matters
The record lists out of bounds read and write classes, CWE-125, CWE-787 and CWE-805, which is a use of the wrong buffer length. A copy routine that works on stale length data can read or write past the intended region.
The risk is bounded by how specific the conditions are. Most Java estates do not run OpenJ9 on IBM Z with this garbage collector option. For the few that do, runtime bugs of this sort deserve a prompt patch because they sit below the application and no application code review would catch them.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect OpenJDK builds from other vendors?
The record covers Eclipse OpenJ9 only. Other runtimes are not named, so check their own advisories.
What is the quickest mitigation?
Upgrade to OpenJ9 0.44.0. If you cannot, the record shows the issue needs the concurrentScavenge option, so turning it off removes that condition. Test first.
Sources
Last reviewed: 19 October 2026.
