Description of the issue

The sun.misc.Unsafe class provides methods for directly accessing memory using memory addresses. It is sometimes used in libraries to achieve better performance compared to equivalent Java memory access.

From a security perspective Unsafe is interesting because if the memory address is incorrect you can crash the JVM (or possibly worse?). This also makes other bug patterns, such as numeric overflow, interesting in this context.

For example:

var field = sun.misc.Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
var unsafe = (sun.misc.Unsafe) field.get(null);

// Crashes the JVM
long badAddress = 1000000000L;
unsafe.getInt(badAddress);

What do you think about adding models and a CodeQL class which represents these sinks? Maybe not directly as part of a query (yet) but in a FlowSinks.qll library (similar to the existing FlowSources.qll).
There is already sun.misc.model.yml but it does not cover Unsafe yet.

Possibly this could also be combined with (future) sinks for other APIs which take native memory addresses as arguments.

Here is my hacky CodeQL code to match these sun.misc.Unsafe sinks:

class UnsafeSink extends DataFlow::Node {
  UnsafeSink() {
    exists(MethodAccess c, Method m, int argIndex |
      m = c.getMethod() and
      m.getDeclaringType().hasQualifiedName("sun.misc", "Unsafe") and
      c.getArgument(argIndex) = this.asExpr()
    |
      m.getName().matches(["get%", "put%"]) and
      (
        m.getParameterType(0) instanceof TypeObject and argIndex = 1
        or
        m.getParameterType(0).hasName("long") and argIndex = 0
      )
      or
      m.hasName("allocateMemory") and argIndex = 0
      or
      m.hasName("reallocateMemory") and argIndex = [0, 1]
      or
      m.hasName("setMemory") and
      (
        m.getParameterType(0) instanceof TypeObject and argIndex = [1, 2]
        or
        m.getParameterType(0).hasName("long") and argIndex = [0, 1]
      )
      or
      m.hasName("copyMemory") and
      (
        m.getParameterType(0) instanceof TypeObject and argIndex = [1, 3, 4]
        or
        m.getParameterType(0).hasName("long") and argIndex = [0, 1, 2]
      )
      or
      m.hasName("freeMemory") and argIndex = 0
      or
      m.getName().matches("compareAndSwap%") and argIndex = 1
      or
      m.getName().matches(["get%Volatile", "put%Volatile"]) and argIndex = 1
      or
      m.getName().matches("putOrdered%") and argIndex = 1
      or
      m.getName().matches(["getAndAdd%", "getAndSet%"]) and argIndex = 1
    )
  }
}

Affected methods (memory address)

getX(Object, ...) / putX(Object, ...):

getX(long) / putX(long, ...):

getXVolatile / putXVolatile:

Affected methods (memory segment length)

These sinks specify the length of a memory segment to copy or set. Similarly to the memory address sinks above they also allow crashing the JVM, but maybe they cannot be used that easily for other attacks (?).

Affected methods (memory allocation size)

Maybe this goes more in the direction of #4582¹, but on the other hand the Unsafe documentation says some safety checks might be omitted, so maybe for invalid values these methods can also cause other incorrect behavior?