Page History

Concurrency related vulnerabilities can manifest themselves when assumptions are made about the multithreaded behavior of derived classes. An Overriding thread-safe methods with methods that are unsafe for concurrent use can result in improper synchronization when a client that depends on the thread-safety promised by the parent inadvertently operates on an instance of the subclass. For example, an overridden synchronized method's contract may can be violated if when a subclass defines provides an implementation that is not safe unsafe for concurrent access. Furthermore, if an overridden method makes concurrency guarantees, even if it is not itself synchronized, the subclass must adhere to those guarantees.use. Such overriding can easily result in errors that are difficult to diagnose. Consequently, programs must not override thread-safe methods with methods that are unsafe for concurrent use.

The locking strategy of classes designed for inheritance should always be documented. This information can subsequently be used to determine an appropriate locking strategy for subclasses (see LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code and LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy)The rule CON04-J. Synchronize using an internal private lock object places stringent documentation requirements on any class that can be subclassed and makes concurrency guarantees.

Noncompliant Code Example (

...

Synchronized Method)

This noncompliant code example defines a overrides the synchronized doSomething() method in a class called SynchronizedBase. the Base class with an unsynchronized method in the Derived class:

class ThreadSafeBaseBase {
  public synchronized void doSomething() {
    // ...	
  }
}

class ThreadUnsafeSubclassDerived extends ThreadSafeBaseBase {
  @Override public void doSomething() {
    // ...		
  }
}

The base method doSomething() method of the Base class can be safely used by many multiple threads. However, if a subclass ThreadUnsafeSubclass overrides the method but leaves it unsynchronized, its instance cannot be safely passed to multiple threads. , but instances of the Derived subclass cannot.

This programming error can be difficult to diagnose This problem is hard to notice because threads that accept instances of ThreadSafeBase Base can also accept instances of its subclasses. Consequently, the threads may incorrectly assume that the subclasses are thread-safeclients could be unaware that they are operating on a thread-unsafe instance of a subclass of a thread-safe class.

Compliant Solution (

...

Synchronized Method)

This compliant solution synchronizes the doSomething() method of the subclass. :

class ThreadSafeBaseBase {
  public synchronized void doSomething() {
    // ...	
  }
}

class ThreadSafeSubclassDerived extends ThreadSafeBaseBase {
  @Override public synchronized void doSomething() {
    // ...		
  }
}

This compliant solution does not violate CON04solution also complies with LCK00-J. Synchronize using an internal Use private lock objectfinal lock objects to synchronize classes that may interact with untrusted code because the accessibility of the class is package-private which is allowable . Package-private accessibility is permitted when untrusted code cannot infiltrate the package.

Compliant Solution (Private Final Lock Object)

This compliant solution ensures that the Derived class is thread-safe by overriding the synchronized doSomething() method of the Base class with a method that synchronizes on a private final lock object.

class Base {

  public synchronized void doSomething() {
    // ...
  }
}

class Derived extends Base {
  private final Object lock = new Object();

  @Override public void doSomething() {
    synchronized (lock) {
      // ...
    }
  }
}

This is an acceptable solution, provided the locking policy of the Derived class is consistent with that of the Base class.

Noncompliant Code Example (

...

Private Lock)

This noncompliant code example defines a doSomething() method in a class called ThreadSafeBase. This method utilizes an internal private lock, the Base class that uses a private final lock in accordance with CON04LCK00-J. Synchronize using an internal Use private lock objectfinal lock objects to synchronize classes that may interact with untrusted code.

class ThreadSafeBaseBase {
  private final Object lock = new Object();

  public void doSomething() {
    synchronized (lock) {
      // ...	
    }
  }
}

class ThreadUnsafeSubclassDerived extends ThreadSafeBaseBase {
  Logger logger = // Initialize

  @Override public void doSomething() {
    // ...
  }
}

The base method can be safely used by many threads. However, if a subclass ThreadUnsafeSubclass overrides the method but provides no concurrency guarantees, its instance cannot be safely passed to multiple threads.

Compliant Solution (private lock)

try {
      super.doSomething();
    } finally {
      logger.log(Level.FINE, "Did something");
    }
  }
}

It is possible for multiple threads to cause the entries to be logged in an order that differs from the order in which the tasks are performed. Consequently, the doSomething() method of the Derived class cannot be used safely by multiple threads because it is not thread-safe.

Compliant Solution (Private Lock)

This compliant solution This compliant solution synchronizes the doSomething() method of the subclass . using its own private final lock object:

class ThreadSafeBaseBase {
  private final Object lock = new Object();

  public void doSomething() {
    synchronized (lock) {
      // ...	
    }
  }
}

class ThreadSafeSubclassDerived extends ThreadSafeBaseBase {
  Logger logger = // Initialize

  private final Object lock = new Object();

  @Override public void doSomething() {
    synchronized (lock) {
      try {
      //  super.doSomething();
      } finally {
        logger.log(Level.FINE, "Did something");
      }
    }
  }
}

Note that the ThreadSafeBase.lock and ThreadSafeSubclass.lock objects are distinct and mutually invisible. Consequently ThreadSafeSubclass can provide some Base and Derived objects maintain distinct locks that are inaccessible from each other's classes. Consequently, Derived can provide thread-safety guarantees similar to ThreadSafeBaseindependent of Base.

Risk Assessment

Failure to provide synchronization in overriding methods Overriding thread-safe methods with methods that are unsafe for concurrent access can result in unexpected behavior.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[API 06|AA. Java References#API 06]\]
\[[SDN 08|AA. Java References#SDN 08]\] Sun bug database, [Bug ID 4294756|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4294756]

Sound automated detection is infeasible; heuristic checks could be useful.

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.TSM00.OSNS	Avoid overriding synchronized methods with non-synchronized methods

Bibliography

...

Image Added Image Added Image AddedVOID CON09-J. Do not invoke alien methods that rely on invariants protected by the same lock object      11. Concurrency (CON)      CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members