The CWE Team wishes to consult with software security experts about possible 
deprecation for "CWE-365: Race Condition in Switch" due to no documented cases 
where it can occur. Feedback is welcome to c...@mitre.org by March 31.
CWE-365 was based on The CLASP Application Security Process section 5.4.6, (c) 
2005 Secure Software, Inc. (see https://cwe.mitre.org/about/sources.html). This 
section of the manual covers the state of a switch statement going stale and 
therefore out of sync. This can only occur if the switch's conditional 
expression is evaluated more than once.

After community feedback and review, we have been unable to find an instance 
where the switch statement is evaluated more than once. Therefore, the state of 
the switch statement can only become stale is when multiple threads are 
operating and one interferes with the expression evaluated by the switch. If we 
are talking about the evaluation being done incorrectly due to multiple 
threads, this would be better characterized as CWE-366: Race Condition within a 

CWE-365's demonstrative example is based on C code taken from CLASP. Each case 
statement must be a constant, and it can't be re-evaluated. In the ANSI 
standards we researched (e.g., ISO/IEC 9899:TC3 
http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf), the specific 
standard does not clearly state that the switch is evaluated once. In 
practicality, the evaluation of the switch statement has been proven to only be 
evaluated once across gcc 3.4.1 through 13.0.1 and clang 4.8.1 through 11.2. 
Analysis of the assembly code for this example confirms it is only evaluated 
once, and thus this weakness cannot occur.
We examined the documentation for several languages including Assembler, Ada, 
ALGOL, COBOL, C++, C#, Erlang, Fortran, F#, Go, Haskell, JavaScript, Lisp, PHP, 
Python, Ruby, Rust, and VB.net. This showed that switch statements and their 
equivalent (e.g., match, case, EVALUATE, select case) specify that the 
evaluation is done only once. Some of them say this and then state that it is 
the equivalent to a series of 'if statements' (which would cause the evaluation 
to be completed multiple times). Despite the ambiguity in the documentation for 
some languages, in practice they all evaluate the Boolean statement once. If 
future languages state that this code explicitly evaluates the Boolean for each 
value, this would not be a weakness but the language performing as designed.

Because CWE-365 is not known to identify any real-world issue, we plan to 
deprecate this weakness in CWE 4.7, which is planned to be released in early 
April. If anybody knows of real-world examples in which a switch conditional is 
evaluated more than once, please notify c...@mitre.org by March 31.

We thank the following people who have reported concerns with CWE-365 and 
helped us conduct the analysis, including representatives from code analysis 
vendors, a co-author of the original CLASP document, members of standards 
groups, and others.
Yongchool Ryu, MathWorks
Roberto Bagnara, BUGSENG
Guido Persch, Imagix
John Blattner, Imagix
Paul Anderson, GrammaTech
Fulvio Baccaglini
John Viega
Members of the CWE-Research mailing list, including Jonathan Hood and Steve 

Thank you
Steve Battista
703 634-9228

Reply via email to