We already have a more conservative check in the compiler (if the
format string is not a literal, we warn). Still adding it here for
completeness and since this check is stronger - only triggered if the
format string is tainted.

llvm-svn: 147714

(Stmt*,LocationContext*) pairs to SVals instead of Stmt* to SVals.

This is needed to support basic IPA via inlining.  Without this, we cannot tell
if a Stmt* binding is part of the current analysis scope (StackFrameContext) or
part of a parent context.

This change introduces an uglification of the use of getSVal(), and thus takes
two steps forward and one step back.  There are also potential performance implications
of enlarging the Environment.  Both can be addressed going forward by refactoring the
APIs and optimizing the internal representation of Environment.  This patch
mainly introduces the functionality upon when we want to build upon (and clean up).

llvm-svn: 147688

as a result of a call.

Problem:
Global variables, which come in from system libraries should not be
invalidated by all calls. Also, non-system globals should not be
invalidated by system calls.

Solution:
The following solution to invalidation of globals seems flexible enough
for taint (does not invalidate stdin) and should not lead to too
many false positives. We split globals into 3 classes:

* immutable - values are preserved by calls (unless the specific
global is passed in as a parameter):
     A :  Most system globals and const scalars

* invalidated by functions defined in system headers:
     B: errno

* invalidated by all other functions (note, these functions may in
turn contain system calls):
     B: errno
     C: all other globals (which are not in A nor B)

llvm-svn: 147569

llvm-svn: 147566

llvm-svn: 147505

Enhance UnixAPIChecker to also warn about zero-sized allocations to calloc() and realloc().  Patch by Cyril Roelandt!

llvm-svn: 147500

from C++ constructors or destructors.  Checker by Lei Zhang with a few tweaks by Ted Kremenek.

llvm-svn: 147494

llvm-svn: 147338

llvm-svn: 147203

llvm-svn: 147139

Check if the input parameters are tainted (or point to tainted data) on
a checkPreStmt<CallExpr>. If the output should be tainted, record it in
the state. On post visit (checkPostStmt<CallExpr>), use the state to
make decisions (in addition to the existing logic). Use this logic for
atoi and fscanf.

llvm-svn: 146793

llvm-svn: 146748

Some of the test cases do not currently work because the analyzer core
does not seem to call checkers for pre/post DeclRefExpr visits.
(Opened radar://10573500. To be fixed later on.)

llvm-svn: 146536

llvm-svn: 146533

Also, allow adding taint to a region (not only a symbolic value).

llvm-svn: 146532

[analyzer] CStringChecker should not rely on the analyzer generating UndefOrUnknown value when it cannot reason about the expression.

We are now often generating expressions even if the solver is not known to be able to simplify it. This is another cleanup of the existing code, where the rest of the analyzer and checkers should not base their logic on knowing ahead of the time what the solver can reason about. 

In this case, CStringChecker is performing a check for overflow of 'left+right' operation. The overflow can be checked with either 'maxVal-left' or 'maxVal-right'. Previously, the decision was based on whether the expresion evaluated to undef or not. With this patch, we check if one of the arguments is a constant, in which case we know that 'maxVal-const' is easily simplified. (Another option is to use canReasonAbout() method of the solver here, however, it's currently is protected.)

This patch also contains 2 small bug fixes:
 - swap the order of operators inside SValBuilder::makeGenericVal.
 - handle a case when AddeVal is unknown in GenericTaintChecker::getPointedToSymbol.

llvm-svn: 146343

llvm-svn: 146146

between the casted type of the return value of a malloc/calloc/realloc
call and the operand of any sizeof expressions contained within
its argument(s).

llvm-svn: 146144

for a foldable constant rather than an IR-level constant. This is still far too
liberal, but is a step in the right direction.

llvm-svn: 145990

for finding dependent symbols for taint.

llvm-svn: 145986

llvm-svn: 145984

(Previously, Clang used it's implementation of dominators.)

The patch is contributed by Guoping Long!

llvm-svn: 145858

of relying on SymbolID.

This way any expression can be printed (not only SymbolData).

llvm-svn: 145829

llvm-svn: 145827

We trigger an error if free is called after a possibly failed allocation. Do not trigger the error if we know that the buffer is not null.

llvm-svn: 145584

We are getting name of the called function or it's declaration in a few checkers. Refactor them to use the helper function in the CheckerContext. 

llvm-svn: 145576

explicit template specializations (which represent actual functions somebody wrote).

Along the way, refactor some other code which similarly cares about whether or
not they are looking at a template instantiation.

llvm-svn: 145547

llvm-svn: 145506

llvm-svn: 145495

There is an open radar to implement better scanf checking as a Sema warning. However, a bit of redundancy is fine in this case.

llvm-svn: 144964

llvm-svn: 144829

Change the ArrayBoundCheckerV2 to be more aggressive in reporting buffer overflows
when the offset is tainted. Previously, we did not report bugs when the state was
underconstrained (not enough information about the bound to determine if there is
an overflow) to avoid false positives. However, if we know that the buffer
offset is tainted - comes in from the user space and can be anything, we should
report it as a bug.

+ The very first example of us catching a taint related bug.
This is the only example we can currently handle. More to come...

llvm-svn: 144826

The checker is responsible for defining attack surface and adding taint to symbols.

llvm-svn: 144825

many checkers are trying to get a name of the callee when visiting
a CallExpr, so provide a convenience API.

llvm-svn: 144820

[static analyzer] Tweak RetainCountChecker's diagnostics to correctly indicate if a message was due to a property access.  This can
potentially be refactored for other clients, and this is a regression from the refactoring of property acceses.

llvm-svn: 144571

literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.

llvm-svn: 144265

Analysis by Ted:
"
    if (stateZero && !stateNotZero) {

is checking to see if:

  (A)  "it is possible for the value to be zero"   (stateZero)

    AND

  (B) "it is not possible for the value to be non-zero"  (!stateNotZero)

That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check.  For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests.  So the question is whether or not such an infeasible path might not get dropped earlier?  I can't envision any right now.

Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:

    C.addTransition(stateNotZero);
"

llvm-svn: 144114

llvm-svn: 143787

Remove unnecessary calls to CheckerContext::getPredecessor() + Comments.

llvm-svn: 143513

[analyzer] ObjC message sends to nil receivers that return structs are now okay (compiler zeroes out the data).  Fixes <rdar://problem/9151319>.

llvm-svn: 143215