Wiki Markup |
---|
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|AA. Java References#API 06]\], class {{ReentrantLock}} documentation: |
...
A
ReentrantLock
is owned by the thread last successfully locking, but not yet unlocking it. A thread invokinglock
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 fails to release the lock on an exceptional condition. Control flow transfers to the catch
block and the call to unlock()
does not execute.
Code Block | ||
---|---|---|
| ||
{quote} 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. {quote} This means that an unreleased lock in any thread will stop other threads from acquiring the same lock. h2. Noncompliant Code Example (checked exception) This noncompliant code example protects a resource by using a {{ReentrantLock}} but fails to release the lock on an exceptional condition. Control flow transfers to the {{catch}} block and the call to {{unlock()}} does not execute. {code:bgColor=#FFcccc} 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 } } {code} 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 held when the finally clause executes.
Code Block | ||
---|---|---|
| ||
. h2. 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 held when the finally block executes. {code:bgColor=#ccccff} 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.
Code Block | ||
---|---|---|
| ||
{code} h2. 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]. {mc} Do not declare lock as private as it need package-wide accessibility for illustrative purposes {mc} {code:bgColor=#FFcccc} 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(); } } {code} 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. h2. |
...
Compliant Solution |
...
This compliant solution adds a {{finally}} block and moves the {{unlock()}} call into it. |
...
Code Block | ||
---|---|---|
| ||
{code:bgColor=#ccccff} 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) { try { lock.lock(); String dateString = date.toString(); if (str.equals(dateString)) { // ... } } finally { lock.unlock(); } } } {code} 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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
CON15- J | low | likely | low | P9 | L2 |
Automated Detection
TODO
Related Vulnerabilities
References
...
. h2. Exceptions *EX1* : Intrinsic locks of class objects are associated with the use of the {{synchronized}} keyword, and are automatically released on exceptional conditions such as abnormal thread termination. h2. Risk Assessment Failing to release a lock on an exceptional condition may lead to thread starvation and deadlock. || Rule || Severity || Likelihood || Remediation Cost || Priority || Level || | CON15- J | low | likely | low | {color:#cc9900}{*}P9{*}{color} | {color:#cc9900}{*}L2{*}{color} | h3. Automated Detection TODO h3. Related Vulnerabilities [GERONIMO-2234|http://issues.apache.org/jira/browse/GERONIMO-2234] h2. References \[[API 06|AA. Java References#API 06]\] Class {{ReentrantLock}} |
...
---- [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON14-J. Ensure atomicity of 64-bit |
...
operations] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON16-J. Do not expect sleep(), yield() and getState() methods to have any synchronization semantics] |