Race Condition in Switch
The code contains a switch statement in which the switched variable can be modified while the switch is still executing, resulting in unexpected behavior.
This issue is particularly important in the case of switch statements that involve fall-through style case statements - i.e., those which do not end with break. If the variable being tested by the switch changes in the course of execution, this could change the intended logic of the switch so much that it places the process in a contradictory state and in some cases could even result in memory corruption.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
This example has a switch statement that executes different code depending on the current time.
It seems that the default case of the switch statement should never be reached, as st_ctime % 2 should always be 0 or 1. However, if st_ctime % 2 is 1 when the first case is evaluated, the time may change and st_ctime % 2 may be equal to 0 when the second case is evaluated. The result is that neither case 1 or case 2 execute, and the default option is chosen.
This category identifies Software Fault Patterns (SFPs) within the Missing Lock cluster (SFP19).
Weaknesses in this category are related to concurrent use of shared resources.
This view (slice) covers all the elements in CWE.
This view (slice) lists weaknesses that can be introduced during implementation.
This view (slice) displays only weakness base elements.