[C-safe-secure-studygroup] "no unused <blah>" rules

Martin Sebor msebor at gmail.com
Wed Mar 15 19:11:08 UTC 2017


>> Apple's Goto Fail bug is an example of a vulnerability caused
>> by dead code due to a spurious goto statement: CVE-2014-1266.
>
> I would say that bug wasn't caused by dead code. The code jumped over
> by the spurious goto is never executed, so it does not meet the
> definition of dead code in MISRA 2.2. The wording in the rule says
> specifically "any operation that is executed", and that code is
> unconditionally not executed. I think the Apple Goto Fail bug is
> covered by 2.1, which is about unreachable code.

Yes, that's true.  I obviously conflated the two rules (even
though my own definition for 2.2 is "reachable statements with
no effect").

Nevertheless, both 2.1 and 2.2 (i.e., unreachable code and
statements with no effect) have the same potential to impact
code quality, security, and safety, and are probably not
differentiated by security analysts when classifying
vulnerabilities.  The goto fail bug can easily be rewritten
using an expression with no effect, and likewise, any example
of 2.2 can trivially be changed into one of 2.1.

I do think both 2.1 and 2.2 should be included in both profiles.
Certainly, if one of them is I see no reason to exclude the other.

Martin

PS This discussion again highlights the ambiguous specification
of some MISRA rules.  As specified, 2.2 is indistinguishable from
2.1:

   Any executed operation whose removal would not affect program
   output constitutes dead code. The presence of dead code may be
   indicative of an error in the program's logic.

Operations whose removal doesn't affect program output are
routinely removed by compilers and thus are not executed.  The
effects of both non-compliant statements in 2.2 are removed,
much like the unreachable code in the example in 2.1 can be.

There is no difference between two rules (we're just guessing
from the rationale and examples that 2.1 is about control flow
and compound statements and 2.2 is about expressions).

Martin



More information about the C-safe-secure-studygroup mailing list