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

An exceptional condition may circumvent the release of a lock. This can result in thread starvation and deadlock. According to the Java API [[API 06]], class ReentrantLock documentation:

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.

This means that an unreleased lock in any thread will stop other threads from acquiring the same lock.

Noncompliant Code Example (checked exception)

This noncompliant code example protects a resource by using a ReentrantLock but on an exceptional condition, fails to release the lock. Control flow transfers to the catch block and the call to unlock() does not execute.

public void doSomething(File file) {
  final Lock lock = new ReentrantLock();
  try {
    lock.lock();
    InputStream in = new FileInputStream( file);
    // Do something with 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

This compliant solution uses a try-finally block immediately after acquiring the lock. This ensures that the lock is appropriately released even in the event of an exceptional condition. Also the lock is acquired outside the try block, which guarantees that the lock is actually obtained when the finally clause executes.

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 protects the thread-unsafe Date instance using a ReentrantLock. It also needs to catch Throwable to be compliant with EXC06-J. Do not allow exceptions to transmit sensitive information.

class DateHandler {
  private 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

This compliant solution adds a finally block and moves the unlock() call into it.

class DateHandler {
  private 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) {
    try {
      lock.lock();
      String dateString = date.toString();
      if (str.equals(dateString)) {
        // ...
      }
    } finally {
      lock.unlock();
    }
  }
}

Consequently, the lock is released successfully even in the event of a runtime exception.

Exceptions

EX1 : Intrinsic locks are associated with the use of the synchronized keyword, and are automatically released on exceptional conditions such as abnormal thread termination.

Risk Assessment

Failing to release a lock on an exceptional condition may lead to thread starvation and deadlock.

Automated Detection

TODO

Related Vulnerabilities

GERONIMO-2234

References

[[API 06]] Class ReentrantLock

VOID CON14-J. Ensure atomicity of 64-bit operations      11. Concurrency (CON)      CON16-J. Do not expect sleep() and yield() methods to have any synchronization semantics