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