CON15-J. Ensure actively held locks are released on exceptional conditions

An exceptional condition can circumvent the release of a lock, leading to deadlock. According to the Java API, class ReentrantLock documentation [[API 06]]:

A ReentrantLock is owned by the thread last successfully locking, but not yet unlocking it. A thread invoking lock will return, successfully acquiring the lock, when the lock is not owned by another thread.

Consequently, an unreleased lock in any thread will stop other threads from acquiring the same lock. This is not an issue for classes that only use method or block synchronization because these concurrency primitives ensure that their monitor locks are released on exceptional conditions.

Noncompliant Code Example (Checked Exception)

This noncompliant code example protects a resource using a ReentrantLock but fails to release the lock if an exception occurs while performing operations on the open file. In an exception is thrown, control transfers to the catch block and the call to unlock() is not executed.

public void doSomething(File file) {
  final Lock lock = new ReentrantLock();
  try {
    lock.lock();
    InputStream in = new FileInputStream(file);
    // Perform operations on the open file.
    lock.unlock();
  } catch (FileNotFoundException fnf) {
    // Handle the exception
  }
}

Note that the lock is not released, even when the doSomething() method returns.

Compliant Solution (finally block)

This compliant solution encapsulates operations that may throw an exception in a try block immediately after acquiring the lock. The lock is acquired just before the try block, which guarantees that it is held when the finally block executes.
The lock is released in the corresponding finally block, which ensures the lock is released regardless of whether or not an exception occurs.

public void doSomething(File file) {
  final Lock lock = new ReentrantLock();
  lock.lock();
  try {
    InputStream in = new FileInputStream(file);
    // Do something with the open file.
  } catch(FileNotFoundException fnf) {
    // Handle the exception
  } finally {
    lock.unlock();
  }
}

Noncompliant Code Example (unchecked exception)

This noncompliant code example uses a ReentrantLock to protect a java.util.Date instance, which is not thread-safe by design. It also needs to catch Throwable to be compliant with [EXC06-J. Do not allow exceptions to transmit sensitive information].

final class DateHandler {
  private final Date date = new Date();
  final Lock lock = new ReentrantLock();

  public void doSomethingSafely(String str) {
    try {
      doSomething(str);
    } catch(Throwable t) {
      // Forward to handler
    }
  }

  public void doSomething(String str) {
    lock.lock();
    String dateString = date.toString();
    if (str.equals(dateString)) {
      // ...
    }
    lock.unlock();
  }
}

However, because the doSomething() method does not check whether str is null, a runtime exception in this component may prevent the lock from being released.

Compliant Solution (try-finally block)

This compliant solution adds a finally block that contains the unlock() call.

final class DateHandler {
  private final Date date = new Date();
  final Lock lock = new ReentrantLock();

  public void doSomethingSafely(String str) {
    try {
      doSomething(str);
    } catch(Throwable t) {
      // Forward to handler
    }
  }

  public void doSomething(String str) {
    lock.lock();
    try {
      String dateString = date.toString();
      if (str != null && str.equals(dateString)) {
        // ...
      }
    } finally {
      lock.unlock();
    }
  }
}

Consequently, the lock is released even in the event of a runtime exception. The doSomething() method also checks the string for null to avoid the NullPointerException.

Exceptions

EX1 : Intrinsic locks of class objects used for method and block synchronization are automatically released on exceptional conditions such as abnormal thread termination.

Risk Assessment

Failing to release locks on exceptional conditions may lead to thread starvation and deadlock.

Automated Detection

TODO

Related Vulnerabilities

GERONIMO-2234

References

[[API 06]] Class ReentrantLock

[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!]