Possible Null Pointer Dereference in MustCallConsistencyAnalyzer.java

Overview

In file: MustCallConsistencyAnalyzer.java, there is a potential case of null pointer dereference. In method incrementMustCallImpl inside class MustCallConsistencyAnalyzer, there is a call to TypesUtils.getTypeElement. Then getQualifiedName method is invoked on the supposedly returned TypeElement object.

  private void incrementMustCallImpl(TypeMirror type) {
    // only count uses of JDK classes, since that's what the paper reported
    if (!isJdkClass(TypesUtils.getTypeElement(type).getQualifiedName().toString())) {
      return;
    }
    checker.numMustCall++;
  }

But getTypeElement method of class TypesUtils can return null if the provided TypeMirror object doesn't correspond to a valid TypeElement object.

  public static @Nullable TypeElement getTypeElement(TypeMirror type) {
    Element element = ((Type) type).asElement();
    if (element == null) {
      return null;
    }
    if (ElementUtils.isTypeElement(element)) {
      return (TypeElement) element;
    }
    return null;
  }

If that happens it will cause a NullPointerException.

It is not immediately clear whether parameter type can always be converted to a TypeElement object when calling incrementMustCallImpl. In that case fixing it might seem unnecessary, but it is always recommended to not assume anything about data coming from outside a class.

Sponsorship and Support:

This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed - to improve global software supply chain security.

The bug is found by running the iCR tool by OpenRefactory, Inc. and then manually triaging the results.

Start in checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java at incrementMustCallImpl and inspect the TypesUtils.getTypeElement contract. Determine how a null result should be handled and whether callers can supply a non-TypeElement type. Confirm the behavior with the existing checker test suite; done means no null dereference while preserving JDK-class counting.