On the unsafety of sun.misc.Unsafe

some-java-user-99206970363698485155 at vodafonemail.de some-java-user-99206970363698485155 at vodafonemail.de
Tue Sep 16 21:15:20 UTC 2025


Hello,

when Maurizio Cimadamore and Per-Ake Minborg wrote about sun.misc.Unsafe 
a few months ago [1], it might have been a bit abstract what it actually 
means for Unsafe to be "unsafe" and what the effects can be.

During the past months I was looking into this topic, and one result of 
this is CVE-2024-36114 for a third-party library using Unsafe: Missing 
bounds checks for Unsafe usage allowed crashing the JVM and possibly 
leaking unrelated data of the JVM process
I don't want to discredit the authors of that library with this, instead 
I want to point out how easily such issues can occur and what 
consequences they can have.
Neither do I want to imply that Unsafe usage is generally bad, however 
it can certainly be risky, especially if used in a situation where 
untrusted data is processed.

So from a stability and security perspective I think it was a good 
decision by the JDK maintainers to deprecate the Unsafe memory access 
methods (JEP 471) and to issue warnings on their usage (JEP 498).

For Unsafe even small issues such as missing bounds checks or numeric 
overflow can have pretty big consequences, whereas in regular Java code 
you would most likely merely get a runtime exception. IDEs and code 
scanning tools are probably not that helpful here either because to them 
the calls to Unsafe just look like regular method calls; the tools are 
unaware of the effects incorrect arguments can have.
My impression is that Unsafe did not get a lot attention from security 
researchers in the past years, and that little tooling exists to detect 
invalid memory access performed by Unsafe. Additionally, the JDK itself 
has no built-in functionality to validate Unsafe memory access either.


As part of my research I developed a tool for detecting invalid memory 
access performed by Unsafe: 
https://github.com/Marcono1234/unsafe-address-sanitizer
It uses Java instrumentation to inject additional validation into Unsafe.

Also, the JVM fuzzer Jazzer 
(https://github.com/CodeIntelligenceTesting/jazzer) has been extended in 
the latest version 0.25.0 to detect invalid array memory access 
performed by Unsafe.

So if you are developing a project which uses Unsafe or want to 
investigate the safety of a library using Unsafe, maybe give the 
sanitizer or Jazzer a try (and for issues you find in third-party 
libraries, report them privately to their maintainers please). Feedback 
for unsafe-address-sanitizer is highly appreciated! I hope it is useful 
for further improving the safety of the Java ecosystem.

Using Jazzer is also rather straightforward, see the Jazzer README [2]. 
When running fuzzing for a third-party library you also need a 
`src/test/resources/junit-platform.properties` file containing 
`jazzer.instrument=com.example.**` (using the actual package name of the 
library).


Thanks to the JDK maintainers for their efforts on making the Java 
runtime safer and for making it more obvious when third-party libraries 
you are using rely on Unsafe.

Kind regards


(I hope it is ok that I wrote to this mailing list and that it is enough 
on-topic. I considered writing to panama-dev instead but since this mail 
here is not directly related to FFM API development or similar, I 
assumed it would not be suitable there.)
(Note that I am not affiliated with Jazzer or the company maintaining it.)


[1] https://inside.java/2025/06/12/ffm-vs-unsafe/
[2] 
https://github.com/CodeIntelligenceTesting/jazzer?tab=readme-ov-file#junit-5




More information about the discuss mailing list