Page History

...

The use of {{ThreadLocal}} objects isrequires insecurecare in classes whose objects are required to be executed by multiple threads in a thread pool. The technique of thread pooling allows threads to be reused when thread creation overhead is too expensive or creating an unbounded number of threads can affect the reliability of the system. Every thread that enters the pool expects to see an object in its initial, default state. However, when {{ThreadLocal}} objects are modified from a thread which is subsequently made available for reuse, the reused thread sees the state of the {{ThreadLocal}} object as set by the previous thread instead of the expected default state \[[JPL 06|AA. Java References#JPL 06]\].

Noncompliant Code Example

This noncompliant code example consists of an enumeration of days (Day) and two classes (Diary and DiaryPool). The class Diary uses a ThreadLocal variable to store thread-specific information, such as each thread's current day. The initial value of the current day is Monday; this can be changed later by invoking the setDay() method. The class also contains a threadSpecificTask() instance method that performs a thread-specific task.

...

In this execution order, it is expected that the two tasks (t₁ and t₁₂) started using doSomething2() will observe the current day as Monday, however, because pool thread 1 is reused (t₃) observes the day to be Friday .

Noncompliant Code Example (Increase Thread Pool Size)

This noncompliant code example increases the size of the thread pool from two to three to mitigate the issue.

...

Although this produces the required results for this example, it is not a scalable solution because changing the thread pool size is inadequate when more tasks can be submitted to the pool.

Compliant Solution (try-finally Clause)

This compliant solution adds the removeDay() method to the Diary class and wraps the statements in the doSomething1() method of class DiaryPool in a try-finally block. The finally block restores the initial state of the thread-local object days by removing the current thread's value from it.

...

If the thread-local variable is read by the same thread again, it is reinitialized using {{initialValue()}} unless the thread explicitly sets the value before this happens \[[API 06|AA. Java References#API 06]\]. This solution transfers the burden of maintainability to the client ({{DiaryPool}}) but is a good option when the {{Diary}} class cannot be modified.

Compliant Solution (

...

beforeExecute())

In this This compliant solution , the class Diary does not use a ThreadLocal object. Also, the class DiaryPool uses local instances of class Diary within the methods doSomething1() and doSomething2(). The Day is uniquely maintained by each instance of the Diary classuses a custom ThreadPoolExecutor that extends ThreadPoolExecutor and overrides the beforeExecute() method. This method is invoked before the Runnable is executed in the specified thread. It is used to re-initialize the thread local variable before task r is executed by thread t.

publicclass finalCustomThreadPoolExecutor classextends DiaryThreadPoolExecutor {
  privatepublic volatile Day day;

  Diary() {CustomThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
    day = Day.MONDAY; // Default	
  }

  private Day currentDay(long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
    return day;
  }

  public void setDaysuper(Day d) {
    day = d;corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);	
  }

  // Performs some thread-specific task@Override
  public void threadSpecificTaskbeforeExecute()Thread {
t,    // Do task ...
  }
}

public final class DiaryPool Runnable r) {
  private final intif NoOfThreads(t == 2; // Maximum number of threads allowed in pool
  private final Executor exec;

  DiaryPool() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
  }

  public void doSomething1() null || r == null) {
    final Diary diarythrow = new DiaryNullPointerException(); // First instance
    exec.execute(new Runnable() {}
      @Override public void run() {
        diaryDiary.setDay(Day.FRIDAYMONDAY);
    
    diarysuper.threadSpecificTaskbeforeExecute(t, r);
      }
    });
  } 

public final public void doSomething2()class DiaryPool {
    final Diary diary = new Diary(); // Second instance...
    exec.execute(new RunnableDiaryPool() {
    exec = @Override public void run() {new CustomThreadPoolExecutor(NoOfThreads, NoOfThreads,
        diary.threadSpecificTask();
      }
 10, TimeUnit.SECONDS, new }ArrayBlockingQueue<Runnable>(10));
  }

  public static void main(String[] args) {
    DiaryPool dp   diary = new DiaryPoolDiary();
    dp.doSomething1();}
  // Thread 1, requires current day as Friday
    dp.doSomething2(); // Thread 2, requires current day as Monday 
    dp.doSomething2(); // Thread 2, requires current day as Monday
  } 
}

...

...
}

The following table shows a possible execution order that conforms to the requirements:

Exceptions

CON27-EX1: If the state of the ThreadLocal object does not change after initialization, it is safe to use a thread pool. For example, there may be only one type of database connection represented by the initial value of the ThreadLocal object.

Risk Assessment

When objects of classes that use ThreadLocal data are executed in a thread pool by different threads without reinitialization, the objects might acquire stale values, resulting in corrupt state.

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]\] class {{java.lang.ThreadLocal<T>}}
\[[JPL 06|AA. Java References#JPL 06]\] 14.13. ThreadLocal Variables

...