summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Emit an error rather than assert on invalid checker option inputKristof Umann2019-03-086-28/+55
| | | | | | | | | | | Asserting on invalid input isn't very nice, hence the patch to emit an error instead. This is the first of many patches to overhaul the way we handle checker options. Differential Revision: https://reviews.llvm.org/D57850 llvm-svn: 355704
* [analyzer] Use the new infrastructure of expressing taint propagation, NFCKristof Umann2019-03-081-126/+58
| | | | | | | | | | | | | | | | | | | | | | In D55734, we implemented a far more general way of describing taint propagation rules for functions, like being able to specify an unlimited amount of source and destination parameters. Previously, we didn't have a particularly elegant way of expressing the propagation rules for functions that always return (either through an out-param or return value) a tainted value. In this patch, we model these functions similarly to other ones, by assigning them a TaintPropagationRule that describes that they "create a tainted value out of nothing". The socket C function is somewhat special, because for certain parameters (for example, if we supply localhost as parameter), none of the out-params should be tainted. For this, we added a general solution of being able to specify custom taint propagation rules through function pointers. Patch by Gábor Borsik! Differential Revision: https://reviews.llvm.org/D59055 llvm-svn: 355703
* [analyzer] Handle comparison between non-default AS symbol and constantDavid Stenberg2019-03-071-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When comparing a symbolic region and a constant, the constant would be widened or truncated to the width of a void pointer, meaning that the constant could be incorrectly truncated when handling symbols for non-default address spaces. In the attached test case this resulted in a false positive since the constant was truncated to zero. To fix this, widen/truncate the constant to the width of the symbol expression's type. This commit does not consider non-symbolic regions as I'm not sure how to generalize getting the type there. This fixes PR40814. Reviewers: NoQ, zaks.anna, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, jdoerfert, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58665 llvm-svn: 355592
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-1/+3
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [analyzer] Fix taint propagation in GenericTaintCheckerKristof Umann2019-03-051-1/+1
| | | | | | | | | | | The gets function has no SrcArgs. Because the default value for isTainted was false, it didn't mark its DstArgs as tainted. Patch by Gábor Borsik! Differential Revision: https://reviews.llvm.org/D58828 llvm-svn: 355396
* [analyzer] Enable subcheckers to possess checker optionsKristof Umann2019-03-0412-49/+73
| | | | | | | | | | | | | | | | Under the term "subchecker", I mean checkers that do not have a checker class on their own, like unix.MallocChecker to unix.DynamicMemoryModeling. Since a checker object was required in order to retrieve checker options, subcheckers couldn't possess options on their own. This patch is also an excuse to change the argument order of getChecker*Option, it always bothered me, now it resembles the actual command line argument (checkername:option=value). Differential Revision: https://reviews.llvm.org/D57579 llvm-svn: 355297
* Fix file headers. NFCFangrui Song2019-03-015-5/+5
| | | | llvm-svn: 355176
* [analyzer] Fix infinite recursion in printing macrosKristof Umann2019-02-251-1/+11
| | | | | | | | | | | | | | | | #define f(y) x #define x f(x) int main() { x; } This example results a compilation error since "x" in the first line was not defined earlier. However, the macro expression printer goes to an infinite recursion on this example. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57892 llvm-svn: 354806
* [analyzer] MIGChecker: Add support for more APIs.Artem Dergachev2019-02-221-18/+82
| | | | | | | | | | | | | | | Add more "consuming" functions. For now only vm_deallocate() was supported. Add a non-zero value that isn't an error; this value is -305 ("MIG_NO_REPLY") and it's fine to deallocate data when you are returning this error. Make sure that the mig_server_routine annotation is inherited. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58397 llvm-svn: 354643
* [analyzer] MIGChecker: Fix an FN when the object is released in a destructor.Artem Dergachev2019-02-221-3/+18
| | | | | | | | | | | | | | | | | When a MIG server routine argument is released in an automatic destructor, the Static Analyzer thinks that this happens after the return statement, and so the violation of the MIG convention doesn't happen. Of course, it doesn't quite work that way, so this is a false negative. Add a hack that makes the checker double-check at the end of function that no argument was released when the routine fails with an error. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58392 llvm-svn: 354642
* [analyzer] MIGChecker: Improve intermediate diagnostic notes.Artem Dergachev2019-02-221-7/+50
| | | | | | | | | | | | | | | | | | Add a BugReporterVisitor for highlighting the events of deallocating a parameter. All such events are relevant to the emitted report (as long as the report is indeed emitted), so all of them will get highlighted. Add a trackExpressionValue visitor for highlighting where does the error return code come from. Do not add a trackExpressionValue visitor for highlighting how the deallocated argument(s) was(were) copied around. This still remains to be implemented. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58368 llvm-svn: 354641
* [analyzer] MIGChecker: Take advantage of the mig_server_routine annotation.Artem Dergachev2019-02-221-14/+21
| | | | | | | | | | | | | | | | r354530 has added a new function/block/message attribute "mig_server_routine" that attracts compiler's attention to functions that need to follow the MIG server routine convention with respect to deallocating out-of-line data that was passed to them as an argument. Teach the checker to identify MIG routines by looking at this attribute, rather than by making heuristic-based guesses. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/58366 llvm-svn: 354638
* [analyzer] MIGChecker: A checker for Mach Interface Generator conventions.Artem Dergachev2019-02-212-0/+145
| | | | | | | | | | | | | | | | | This checker detects use-after-free bugs in (various forks of) the Mach kernel that are caused by errors in MIG server routines - functions called remotely by MIG clients. The MIG convention forces the server to only deallocate objects it receives from the client when the routine is executed successfully. Otherwise, if the server routine exits with an error, the client assumes that it needs to deallocate the out-of-line data it passed to the server manually. This means that deallocating such data within the MIG routine and then returning a non-zero error code is always a dangerous use-after-free bug. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D57558 llvm-svn: 354635
* [Analyzer] Crash fix for FindLastStoreBRVisitorAdam Balogh2019-02-131-1/+28
| | | | | | | | | | | | | | | | | | | | | | | FindLastStoreBRVisitor tries to find the first node in the exploded graph where the current value was assigned to a region. This node is called the "store site". It is identified by a pair of Pred and Succ nodes where Succ already has the binding for the value while Pred does not have it. However the visitor mistakenly identifies a node pair as the store site where the value is a `LazyCompoundVal` and `Pred` does not have a store yet but `Succ` has it. In this case the `LazyCompoundVal` is different in the `Pred` node because it also contains the store which is different in the two nodes. This error may lead to crashes (a declaration is cast to a parameter declaration without check) or misleading bug path notes. In this patch we fix this problem by checking for unequal `LazyCompoundVals`: if their region is equal, and their store is the same as the store of their nodes we consider them as equal when looking for the "store site". This is an approximation because we do not check for differences of the subvalues (structure members or array elements) in the stores. Differential Revision: https://reviews.llvm.org/D58067 llvm-svn: 353943
* Make some helper functions static. NFC.Benjamin Kramer2019-02-111-3/+2
| | | | llvm-svn: 353705
* [analyzer] New checker for detecting usages of unsafe I/O functionsKristof Umann2019-02-111-3/+95
| | | | | | | | | | | | | | | | There are certain unsafe or deprecated (since C11) buffer handling functions which should be avoided in safety critical code. They could cause buffer overflows. A new checker, 'security.insecureAPI.DeprecatedOrUnsafeBufferHandling' warns for every occurrence of such functions (unsafe or deprecated printf, scanf family, and other buffer handling functions, which now have a secure variant). Patch by Dániel Kolozsvári! Differential Revision: https://reviews.llvm.org/D35068 llvm-svn: 353698
* Use llvm::is_contained. NFCFangrui Song2019-02-101-1/+1
| | | | llvm-svn: 353635
* [analyzer] Add a comment that FunctionCodeRegions may also need canonicalizationArtem Dergachev2019-02-091-0/+1
| | | | llvm-svn: 353592
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-094-21/+852
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* [analyzer] CStringSyntaxChecks: Fix an off-by-one error in the strlcat() check.Artem Dergachev2019-02-081-9/+2
| | | | | | | | | | | | oth strlcat and strlcpy cut off their safe bound for the argument value at sizeof(destination). There's no need to subtract 1 in only one of these cases. Differential Revision: https://reviews.llvm.org/D57981 rdar://problem/47873212 llvm-svn: 353583
* [analyzer] Opt-in C Style Cast Checker for OSObject pointersGeorge Karpenkov2019-02-082-0/+91
| | | | | | Differential Revision: https://reviews.llvm.org/D57261 llvm-svn: 353566
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-074-852/+21
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* Got rid of the `Z3ConstraintManager` classMikhail R. Gadelha2019-02-071-16/+1
| | | | | | | | | | Now, instead of passing the reference to a shared_ptr, we pass the shared_ptr instead. I've also removed the check if Z3 is present in CreateZ3ConstraintManager as this function already calls CreateZ3Solver that performs the exactly same check. Differential Revision: https://reviews.llvm.org/D54976 llvm-svn: 353371
* Generalised the SMT state constraintsMikhail R. Gadelha2019-02-071-26/+36
| | | | | | | | | | | | | | This patch moves the ConstraintSMT definition to the SMTConstraintManager header to make it easier to move the Z3 backend around. We achieve this by not using shared_ptr anymore, as llvm::ImmutableSet doesn't seem to like it. The solver specific exprs and sorts are cached in the Z3Solver object now and we move pointers to those objects around. As a nice side-effect, SMTConstraintManager doesn't have to be a template anymore. Yay! Differential Revision: https://reviews.llvm.org/D54975 llvm-svn: 353370
* [analyzer] Canonicalize declarations within variable regions.Artem Dergachev2019-02-071-0/+2
| | | | | | | | | | | | | | | Memory region that correspond to a variable is identified by the variable's declaration and, in case of local variables, the stack frame it belongs to. The declaration needs to be canonical, otherwise we'd have two different memory regions that correspond to the same variable. Fix such bug for global variables with forward declarations and assert that no other problems of this kind happen. Differential Revision: https://reviews.llvm.org/D57619 llvm-svn: 353353
* Revert "[analyzer] Remove the "postponed" hack, deal with derived symbols..."Artem Dergachev2019-02-061-40/+20
| | | | | | | | | | | | | | This reverts commit r341722. The "postponed" mechanism turns out to be necessary in order to handle situations when a symbolic region is only kept alive by implicit bindings in the Store. Otherwise the region is never scanned by the Store's worklist and the binding gets dropped despite being live, as demonstrated by the newly added tests. Differential Revision: https://reviews.llvm.org/D57554 llvm-svn: 353350
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-022-13/+110
| | | | | | | | | | | | | | | | | | | uninitialized fields This patch is an implementation of the ideas discussed on the mailing list[1]. The idea is to somewhat heuristically guess whether the field that was confirmed to be uninitialized is actually guarded with ifs, asserts, switch/cases and so on. Since this is a syntactic check, it is very much prone to drastically reduce the amount of reports the checker emits. The reports however that do not get filtered out though have greater likelihood of them manifesting into actual runtime errors. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html Differential Revision: https://reviews.llvm.org/D51866 llvm-svn: 352959
* [analyzer] Hotfix for RetainCountChecker: assert was too strong.George Karpenkov2019-02-011-4/+3
| | | | | | Bridged casts can happen to non-CF objects as well. llvm-svn: 352938
* [analyzer] [RetainCountChecker] Fix object type for CF/Obj-C bridged castsGeorge Karpenkov2019-02-011-1/+10
| | | | | | | | | | | | Having an incorrect type for a cast causes the checker to incorrectly dismiss the operation under ARC, leading to a false positive use-after-release on the test. rdar://47709885 Differential Revision: https://reviews.llvm.org/D57557 llvm-svn: 352824
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* [analyzer] [RetainCountChecker] Bugfix for tracking top-level parameters of ↵George Karpenkov2019-01-302-7/+7
| | | | | | | | Objective-C methods Differential Revision: https://reviews.llvm.org/D57433 llvm-svn: 352588
* [analyzer] NFC: GenericTaintChecker: Revise rule specification mechanisms.Artem Dergachev2019-01-301-112/+103
| | | | | | | | | | | | | | | | Provide a more powerful and at the same time more readable way of specifying taint propagation rules for known functions within the checker. Now it should be possible to specify an unlimited amount of source and destination parameters for taint propagation. No functional change intended just yet. Patch by Gábor Borsik! Differential Revision: https://reviews.llvm.org/D55734 llvm-svn: 352572
* [analyzer] [RetainCountChecker] Track input parameters to the top-level functionGeorge Karpenkov2019-01-293-28/+80
| | | | | | | | | | Track them for ISL/OS objects by default, and for NS/CF under a flag. rdar://47536377 Differential Revision: https://reviews.llvm.org/D57356 llvm-svn: 352534
* [analyzer] [ARCMT] [NFC] Unify entry point into RetainSummaryManagerGeorge Karpenkov2019-01-291-3/+3
| | | | | | | | Just use one single entry point, since we have AnyCall utility now. Differential Revision: https://reviews.llvm.org/D57346 llvm-svn: 352532
* Extend AnyCall to handle callable declarations without the call expressionsGeorge Karpenkov2019-01-291-1/+1
| | | | | | | | | | That weakens inner invariants, but allows the class to be more generic, allowing usage in situations where the call expression is not known (or should not matter). Differential Revision: https://reviews.llvm.org/D57344 llvm-svn: 352531
* [analyzer] Toning down invalidation a bitGabor Horvath2019-01-291-5/+17
| | | | | | | | | When a function takes the address of a field the analyzer will no longer assume that the function will change other fields of the enclosing structs. Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 352473
* [analyzer] Fix a typo in docsGabor Horvath2019-01-291-1/+1
| | | | llvm-svn: 352468
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-2613-33/+26
| | | | | | | | | | | | | function registers no more than 1 checker This patch effectively fixes the almost decade old checker naming issue. The solution is to assert when CheckerManager::getChecker is called on an unregistered checker, and assert when CheckerManager::registerChecker is called on a checker that is already registered. Differential Revision: https://reviews.llvm.org/D55429 llvm-svn: 352292
* [analyzer] Reimplement dependencies between checkersKristof Umann2019-01-2613-59/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part. Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it. Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred. This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it. In detail: * Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging. Big thanks to Artem Degrachev for all the guidance through this project! Differential Revision: https://reviews.llvm.org/D54438 llvm-svn: 352287
* [analyzer] Fix an bug where statically linked, but not registered checkers ↵Kristof Umann2019-01-262-8/+14
| | | | | | | | | | | | | | weren't recognized My last patch, D56989, moved the validation of whether a checker exists into its constructor, but we do support statically linked (and non-plugin) checkers that were do not have an entry in Checkers.td. However, the handling of this happens after the creation of the CheckerRegistry object. This patch fixes this bug by moving even this functionality into CheckerRegistry's constructor. llvm-svn: 352284
* [analyzer][NFC] Keep track of whether enabling a checker was explictly ↵Kristof Umann2019-01-261-67/+77
| | | | | | | | | | | | | | | specified in command line arguments I added a new enum to CheckerInfo, so we can easily track whether the check is explicitly enabled, explicitly disabled, or isn't specified in this regard. Checkers belonging in the latter category may be implicitly enabled through dependencies in the followup patch. I also made sure that this is done within CheckerRegisty's constructor, leading to very significant simplifications in its query-like methods. Differential Revision: https://reviews.llvm.org/D56989 llvm-svn: 352282
* [analyzer][NFC] Supply CheckerRegistry with AnalyzerOptionsKristof Umann2019-01-262-19/+17
| | | | | | | | | Since pretty much all methods of CheckerRegistry has AnalyzerOptions as an argument, it makes sense to just simply require it in it's constructor. Differential Revision: https://reviews.llvm.org/D56988 llvm-svn: 352279
* [analyzer] Split unix.API up to UnixAPIMisuseChecker and ↵Kristof Umann2019-01-261-101/+128
| | | | | | | | | | | | | | | | UnixAPIPortabilityChecker The actual implementation of unix.API features a dual-checker: two checkers in one, even though they don't even interact at all. Split them up, as this is a problem for establishing dependencies. I added no new code at all, just merely moved it around. Since the plist files change (and that's a benefit!) this patch isn't NFC. Differential Revision: https://reviews.llvm.org/D55425 llvm-svn: 352278
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-2695-40/+496
| | | | | | | | | | | | | | | | | | Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways. A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed. This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953 Differential Revision: https://reviews.llvm.org/D55424 llvm-svn: 352277
* [analyzer] Port RetainSummaryManager to the new AnyCall interface, decouple ↵George Karpenkov2019-01-255-1264/+33
| | | | | | | | | | ARCMT from the analyzer rdar://19694750 Differential Revision: https://reviews.llvm.org/D57127 llvm-svn: 352149
* [analyzer] Insert notes in RetainCountChecker where our dynamic cast ↵George Karpenkov2019-01-224-7/+27
| | | | | | | | | | modeling assumes 'null' output rdar://47397214 Differential Revision: https://reviews.llvm.org/D56952 llvm-svn: 351865
* [analyzer] Model another special-case kind of cast for OSObject ↵George Karpenkov2019-01-222-8/+25
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D56951 llvm-svn: 351864
* [Analyzer] Remove extra blank line from Iterator Checker (test commit)Adam Balogh2019-01-211-1/+0
| | | | llvm-svn: 351746
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19161-644/+483
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
OpenPOWER on IntegriCloud