fuzz clang #23431
Comments
|
echo -n "#if 0" | clang -x c++ - ==23545==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000006b76 at pc 0x00000bb7006e bp 0x7fffa7ced0f0 sp 0x7fffa7ced0e8 |
|
echo -n '~a::{' | clang -x c++ ==23855==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x00000b7c91c6 bp 0x7fffe68c9dd0 sp 0x7fffe68c9dc0 T0) |
|
Not sure if leaks in clang on invalid inputs are worth fixing. echo "::(&C" | clang -x c++ - Direct leak of 432 byte(s) in 1 object(s) allocated from: |
|
The bot is currently running w/o assertions because there are quite a few of them printf '\n;::(&C' | clang -x c++ - printf 'x(a::(b)' | clang -x c++ - echo ClMKWyK/APABWOsiTD1rW9hs | base64 --decode | clang -x c++ - printf 'k80x&::((**\ne::' | clang -x c++ - |
|
echo -n "#if 0" | clang -x c++ - fixed in r233491. |
|
echo I1zqGiMAXAoAI7JrCiPR | base64 --decode | clang -x c++ - W/o asserts causes null deref. Thanks Benjamin for the fixes! |
|
I added the still-open AFL bugs found by Sami Liedes |
I think they are worth fixing. They would adversely affect the stability of long-lived processes that use clang as a library, such as IDE's. |
|
echo zWsoIi+qACrc8o25aFlrW7YkImJL | base64 --decode | clang -x c++ - -c ==4839==ERROR: AddressSanitizer: negative-size-param: (size=-264) |
|
echo -n "#include<\" | clang -x c++ -c - ==24291==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000006bbb at pc 0x00000bb382d1 bp 0x7fff54ea18d0 sp 0x7fff54ea18c8 0x604000006bbb is located 0 bytes to the right of 43-byte region [0x604000006b90,0x604000006bbb) allocated by thread T0 here: |
|
There are probably quite a few unreported ones at http://sli.dy.fi/~sliedes/clang-triage/triage_report.xhtml . I just added a few new test cases there that bumped the number of distinct crashes from 68 to 88. My bot doesn't automatically fuzz; the fuzzing part is manual, but it runs clang trunk against a generated corpus of (currently ~14k, but probably only 5-6k exercise distinct paths) inputs that have at some point crashed clang. Anyway, glad to hear that there's more advanced fuzzing infrastructure in place now. |
Interestingly, all the cases of leaks I observe also fail assertions in a debug build, see #4. So, if we fix those assertions the leaks may disappear as well. |
This is the reason why the fuzzer bot runs the in-process fuzzer w/o assertions. |
|
Infinite recursion: echo "inlineJ33 y8(struct include; " | clang -x c++ -c - |
|
r233726 disables leak detection for clang-fuzzer until c#4 is fixed. |
|
use-after-free.log ==10808==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110000088e0 at pc 0x0000007dfd49 bp 0x7fff87de5a90 sp 0x7fff87de5248 |
|
echo "g34( struct Yunsignedp char32_t=char32_t_35==ZcregisterZtypename&&S=4autobitand8 &&or* xor{static_cast&char32_t&welseconst auto" | clang -x c++ - tools/clang/include/clang/AST/DeclCXX.h:592: struct DefinitionData &clang::CXXRecordDecl::data() const: Assertion `DD && "queried property of class with no definition"' failed. Leads to a null deref w/o assertions. |
|
echo "f(){for(a operator==:" | clang -x c++ -c - Assertion `Val && "isa<> used on a null pointer"' failed. Sami has this one too. W/o assertions this is another NULL deref. |
|
These two might be variations of c#16 or separate use-after-free bugs. echo 'lshort typedef s4;bool Kt={3LbreaklinethisQ&namespaceifndef[(double(struct{private:}~A/=void ifdef))nullptrchar32_t|$( tnewspublic -=--<' | clang -x c++ -c - ==17685==ERROR: AddressSanitizer: heap-use-after-free on address 0x61500000e740 at pc 0x0000007dfd49 bp 0x7fff53379ef0 sp 0x7fff533796a8 0x61500000e740 is located 192 bytes inside of 456-byte region [0x61500000e680,0x61500000e848) echo '=registerforthisclassxor^u ;conceptBchar32_t=breaku:OB& ifndef[(double(wchar_t nI[3u/23;p= ,signed))nullptr error(Rl' | clang -x c++ -c - ==17945==ERROR: AddressSanitizer: heap-use-after-free on address 0x61500000e758 at pc 0x0000007dfd49 bp 0x7fffc5bc49b0 sp 0x7fffc5bc4168 ... |
|
As of today, issue 22407 is the only one seen on the clang fuzzer bot:a |
(the bot uses no-assertions build) |
the clang/clang-format fuzzer bot
|
|
Still seen by the fuzzer bot: echo w5sKZTtTk1LJKHbBDckJUgksZCg7Kjo6KCooZckokztyyWWROyjJKIM6OsllwSgmQkFyPDooOi87 | base64 --decode | clang++ -x c++ - |
|
some more llvm/include/llvm/Support/Casting.h:95: static bool llvm::isa_impl_cl<clang::ExprWithCleanups, const clang::Expr *>::doit(const From *) [To = clang::ExprWithCleanups, From = const clang::Expr *]: Assertion `Val && "isa<> used on a null pointer"' failed. (null deref follows) |
|
echo O2lubGluZSB0ZW1wbGEoCWNDKSgJIGVudW0gbDY7KHRlIG8= | base64 --decode | clang -x c++ - ==38911==ERROR: AddressSanitizer: stack-overflow on address 0x7ffdfb8a2f00 (pc 0x00000cb04169 bp 0x7ffdfb8a30a0 sp 0x7ffdfb8a2f00 T0) |
|
stack trace for #24 |
|
one more: echo dGVtcGxhdGUgPCF2PmNsYXNzJAlle25tdGwgZSAoIGRvdWxlMipDKXRocm93CyAoKXsgIGUgZDpkKCkhPA== | base64 --decode | clang -x c++ - ==15086==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000001c (pc 0x0000096ce636 bp 0x7ffd5d700ee0 sp 0x7ffd5d700ac0 T0) |
|
tools/clang/lib/AST/DeclBase.cpp:762: bool clang::Decl::AccessDeclContextSanity() const: Assertion `Access != AS_none && "Access specifier is AS_none inside a record decl"' failed. echo IChkb3dsKiYmQykLKChsYXNzeyAgZmxvZXR1dCgJXkMpKAkgZW51bWwgb21wbDtjPDp4b3JfZXEnOiEpOyc | base64 --decode | clang -x c++ - |
In an non-assert build causes this: |
|
Input (base64): bmFtZXNwYWNlICB7YXV0byBsIChedm9sYXRpbGV7b2lubGF1byBsKT1ee2ZhOiBsIG5hfWUmJmwocyggKGho llvm/tools/clang/lib/AST/Decl.cpp:2136: clang::APValue *clang::VarDecl::evaluateValue(SmallVectorImpl &) const: Asse ==17999==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000d2b0a79 bp 0x7ffee1d343b0 sp 0x7ffee1d33e40 T0) |
Endilll
added
the
metabug
Extended Description
As of r233459 we have a clang fuzzer in the source tree.
Details: llvm/lib/Fuzzer/README.txt
We also have a build bot that runs the fuzzer 24/7
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer
(See also bug 23052 for the clang-format fuzzer).
I propose to track all activities related to fuzzing clang here.
(There was a significant volume of bugs detected by AFL,
if someone has the list of revisions/bugs, please attach here).
The text was updated successfully, but these errors were encountered: