Checks

Types of Checks

CodeSonar's analysis engine finds over 100 different types of problems.

Some of the source code analysis checkers are described in the tabs below. (Some binary analysis checkers are listed here.)

CodeSonar's defect checks include:

  • Data Race Condition
    Shared data accessed in an unsafe manner.
  • Deadlock
    Two or more threads prevent each other from making progress.
  • Process Starvation
    A thread of execution may not run.
  • Buffer Overrun (example)
    A read or write to data after the end of a buffer.
  • Leak (example)
    Dynamically allocated storage has not been freed.
  • Null Pointer Dereference (example)
    An attempt to dereference a pointer to the address 0.
  • Type Overrun
    An overrun of a boundary within an aggregate type.
  • Type Underrun
    An underrun of a boundary within an aggregate type.
  • Divide By Zero
    An attempt to perform integer division where the denominator is 0.
  • Double Free
    Two calls to free on the same object.
  • Use After Free
    A dereference of a pointer to a freed object.
  • Free Non-Heap Variable
    An attempt to free an object which was not allocated on the heap, such as a stack-allocated variable.
  • Uninitialized Variable
    An attempt to use the value of a variable that has not been initialized.
  • Dangerous Function Cast
    A function pointer is cast to another function pointer having an incompatible signature or return type.
  • Delete[] Object Created by malloc
    An attempt to release memory obtained with malloc using delete[].
  • Delete[] Object Created by new
    An attempt to release memory obtained with new using delete[].
  • Delete Object Created by malloc
    An attempt to release memory obtained with malloc using delete.
  • Delete Object Created by new[]
    An attempt to release memory obtained with new[] using delete.
  • FreeObject Created by new[]
    An attempt to release memory obtained with new[] using free.
  • Free Object Created by new
    An attempt to release memory obtained with new using free.
  • Missing Return Statement
    At least one path through a non-void return-type function does not contain a return statement.
  • Redundant Condition
    Some condition is either always or never satisfied.
  • Return Pointer To Local
    A procedure returns a pointer to one of its local variables.
  • Return Pointer To Freed
    A procedure returns a pointer to memory that has already been freed.
  • Unused Value
    A variable is assigned a value, but that value is never subsequently used on any execution path.
  • Useless Assignment
    Some assignment always assigns the value that the variable being modified already has.
  • Varargs Function Cast
    A varargs function pointer is cast to another function pointer having different parameters or return type.
  • Ignored Return Value
    The value returned by some function has not been used.
  • Free Null Pointer
    An attempt to free a null pointer.
  • Unreachable Code
    Some of the code in a function is unreachable from the function entry point under any circumstances.
  • Null Test After Dereference
    A pointer is NULL-checked when it has already been dereferenced.
  • Format String
    A function that should have a format string passed in a particular argument position has been passed a string that either is not a format string or is from an untrusted source. (Potential security vulnerability.)
  • Double Close
    An attempt to close a file descriptor or file pointer twice.
  • TOCTTOU Vulnerability
    A time-of-check-to-time-of-use race condition that can create a security vulnerability.
  • Double Lock
    An attempt to lock a mutex twice.
  • Double Unlock
    An attempt to unlock a mutex twice.
  • Try-lock that will never succeed
    An attempt to lock a mutex that cannot possibly succeed.
  • Misuse of Memory Allocation
    Incorrect use of memory allocators.
  • Misuse of Memory Copying
    Incorrect use of copying functions.
  • Misuse of Libraries
    Misuse of standard library functions.
  • User-Defined Bug Classes
    Checks for arbitrary bug classes can be implemented through the CodeSonar extension functions.

Checks for Multi-Threaded and Multi-Core Code

Pinpoint data races and other concurrency-related errors.

CodeSonar detects complex concurrency-related defects in multi-threaded and multi-core code. It discovers and enforces global program invariants, such as the relationship between locks and shared memory locations. CodeSonar then flags the following types of concurrency-related vulnerabilities.

  • Data Races

    Multiple threads access shared data in an unsafe way.

    Data races cause a disproportionate number of concurrency-related bugs, and CodeSonar's data race detection is extremely effective. A data race arises when:

    1. Multiple threads of execution access a shared piece of data.
    2. At least one thread changes the value of the data.
    3. Access is not separated by explicit synchronization.

    Data races can leave a system in an inconsistent state. They can lurk undetected and only show up in unusual circumstances with mysterious symptoms.

    The challenge with detecting and debugging data races (and concurrency problems in general) using traditional testing is that there are an enormous number of possible execution interleavings. Consider the diagram below.

    There are six possible interleavings of two threads with two instructions each. With three instructions each, there are twenty possible interleavings. Due to the combinatorial explosion, it is infeasible to test every interleaving in real-world systems. Yet data races occur only under certain interleavings, making diagnosis using traditional methods difficult. Data races are also sensitive to traditional tools like debuggers, which affect timing and can make the bug disappear temporarily.

    CodeSonar detects data races by focusing on the causes, not the symptoms. It examines the code and creates an abstract model of what locks are held by what threads. It considers possible interleavings in an automated way, examining patterns of access to shared memory locations, and finds situations in which code is susceptible to problematic interleavings. When a data race is identified, CodeSonar issues a data race warning that includes supporting information.

    A widespread assumption is that some types of data races are harmless. However, this assumption is actually false. Even if the race condition looks benign in the source code, it very well may cause harm during execution because optimizing compilers reorder instructions. For more information about this phenomenon, see the paper How to miscompile programs with “benign” data races by Hans Boehm of HP Labs, in the HotPar'11 Proceedings of the 3rd USENIX conference on Hot topics in parallelism.

  • Deadlock

    Two or more threads prevent each other from making progress by each holding a lock needed by another.

    The most common approach to avoiding deadlock is to ensure a partial ordering to the resources. This approach was proposed by Dijkstra in 1965 as a solution to the Dijkstra/Hoare Dining Philosophers Problem. In a large code base, it can be difficult to tell through manual inspection if the software adheres to this rule. CodeSonar performs an automated analysis and issues a warning if the same locks can be acquired in different orders by different threads.

    CodeSonar also provides a nested locks check, which is more aggressive and used by some developers of critical systems. This check triggers a warning whenever a thread tries to obtain two or more locks. The nested lock check may be enabled or disabled, depending on requirements.

  • Incorrect Use of Synchronization Techniques

    Lock/unlock mismatches, try-locks that will never succeed, long-pending operations within critical regions, and other problems.

CodeSonar brings efficiency to security compliance.

CodeSonar's advanced static analysis engine automatically detects over 100 kinds of possible security vulnerabilities in your code, so you can accurately and efficiently eliminate risks of security breaches. Security checkers include Buffer Overrun, Type Overruns, Null Pointer Dereferences, File System Race Condition, and Division by Zero.

To make compliance with industry standards more efficient, CodeSonar's warning classes also support several coding initiatives, including the CWE and BSI initiatives, described in more detail below.

Common Weakness Enumeration (CWE):

CWE Mapping for CodeSonar Read the PDF

The Common Weakness Numeration (CWE) initiative is focused on creating a common set of software security vulnerability descriptions. Such a set allows clear communication between different parties with interests in computer security, including researchers, tool designers, and users.

Click on the PDF to the left to view the CodeSonar warning classes that correspond with CWE identifiers.

"Build Security In" (BSI):

BSI Mapping for CodeSonar Read the PDF

BSI is a software assurance initiative of the U.S. Department of Homeland Security. Among other things, they provide a set of C/C++ coding rules, with a focus on security. CodeSonar provides checks in support of most of these rules.

Click on the PDF to the left to view the CodeSonar warning classes that correspond with the BSI coding rules.

CodeSonar Supports Reliability Standards

To make compliance with industry standards more efficient, CodeSonar's warning classes support the following coding initiatives.

"Power of Ten":

Power of 10 Mapping for CodeSonar Read the PDF

The "Power of Ten" refers to a set of ten rules developed by Gerard Holzmann of the NASA Jet Propulsion Laborator for use in writing safety-critical software. The rules are simple, but they specify strict limits on the forms code can take. These limits support code clarity and analyzability, which are especially important for safety-critical applications.

Click on the PDF to the left to view the CodeSonar warning classes that correspond with the "Power of Ten" rules.

JPL Rules:

JPL Mapping for CodeSonar Read the PDF

JPL rules refer to the JPL Institutional Coding Standards for the C Programming Language. JPL coding rules address software risks related to the use of multi-threaded software, building on the "Power of Ten" coding rules and the MISRA-C coding guidelines for safety-critical applications.

Click on the PDF to the left to view the CodeSonar warning classes that correspond with JPL rules.
Free Trial of CodeSonar

Watch a 4-minute
demo of Codesonar:

CodeSonar Demo
glqxz9283 sfy39587stf02 mnesdcuix8
sfy39587stf03
sfy39587stp14