Reviewing Code for Race Conditions

Revision as of 07:04, 13 August 2007 by EoinKeary (talk | contribs)

Jump to: navigation, search
OWASP Code Review Guide Table of Contents


Race conditions: Race Conditions occur when a piece of code does not work as it is supposed to (like many security issues). They are the result of an unexpected ordering of events which can result in the finite state machine of the code to transition to a undefined state and also give rise to contention of more than one thread of execution over the same resource. Multiple threads of execution acting or manipulating the same area in memory or persisted data which gives rise to integrity issues.

How they work:

With competing tasks manipulating the same resource we can easly get a race condition as the resource is not in step-lock or utilises a token based multi-use system such as semaphores.

Say we have two processes (Thread 1, T1) and (Thread 2, T2). The code in question adds 10 to an integer X. The initial valus of X is 5.

X = X + 10

So with no controls surrounding this code in a multithreaded environment we get the following problem:

T1 places X into a register in thread 1
T2 places X into a register in thread 2
T1 adds 10 to the value in T1's register resutling in 15
T2 adds 10 to the value in T2's register resulting in 15
T1 saves the register value (15) into X.
T1 saves the register value (15) into X.

The value shoild actually be 25 as each Thread added 10 to the initial value of 5. But the actual value is 15 due to T2 not letting T1 save into X before it takes a value of X for its addition.

How to locate the potentially vulnerable code


Look for code which used multithreaded environments:

Keywords such as:




Vulnerable Patterns for Race Conditions

Good Patterns & procedures to prevent Race Conditions

Related Articles