[llvm] r271139 - [llvm-readobj] Validate the string table offset before using it

Tue May 31 13:36:08 PDT 2016

On Tue, May 31, 2016 at 1:25 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

>
> On Tue, May 31, 2016 at 1:13 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Tue, May 31, 2016 at 1:07 PM, David Majnemer <david.majnemer at gmail.com
>> > wrote:
>>
>>>
>>>
>>> On Tue, May 31, 2016 at 11:50 AM, Kostya Serebryany <kcc at google.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, May 29, 2016 at 2:25 PM, David Blaikie via llvm-commits <
>>>> llvm-commits at lists.llvm.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, May 29, 2016 at 10:09 AM, David Majnemer <
>>>>> david.majnemer at gmail.com> wrote:
>>>>>
>>>>>> Not really, I have no way to reduce the test down to something
>>>>>> reasonable.  I'd rather not see the LLVM repo become a collection of large,
>>>>>> malformed PDB files.
>>>>>>
>>>>>
>>>>> Other ideas for how we ensure we don't regress the functionality
>>>>> you're adding? Sounds like this sort of idea is what Kostya has in mind for
>>>>> libFuzzer use - a corpus of interesting inputs that grows when bugs are
>>>>> fixed so the corpus can be run directly for regression testing, and used as
>>>>> input to the fuzzer for bug finding. Perhaps we need to formalize something
>>>>> like that for this sort of work?
>>>>>
>>>>
>>>> If someone creates a fuzz target code (similar to e.g.
>>>> tools/clang/tools/clang-fuzzer/ClangFuzzer.cpp) it will be straightforward
>>>> to add such a fuzzer to the fuzzing bot
>>>> <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/9533>
>>>> .
>>>> The only question is whether someone will care to fix the bugs -- clang
>>>> and clang-format fuzzers are red for many months.
>>>>
>>>
>>> I've fuzzed llvm-pdbdump with AFL to the point where no bugs showed up.
>>> I've also written a libfuzzer target, llvm-pdbdump-fuzzer, which hasn't
>>> found any crashes.
>>>
>> Do you want to run it on the bot?
>> Just add it here: ./zorg/buildbot/builders/sanitizers/buildbot_fuzzer.sh
>>
>
> Sure but I'm afraid I can't find any instructions on how to get the corpus
> from the LLVM testsuite into the fuzzer itself.
>

There aren't many instructions (I did not have a reason to invest into
documentation given that the bugs were not fixed).
I've just created an empty dir
gs://fuzzing-with-sanitizers/llvm/pdbdump/C1.
In buildbot_fuzzer.sh you need to make sure it's synchronized the same way
as clang and clang-format dirs. (syncToGs and syncFromGs)
If you want to use a directory with samples as the initial seed (good
idea!) pass it as a second corpus:
(${STAGE2_ASAN_ASSERTIONS_DIR}/bin/pdbdump-fuzzer -max_len=64 -jobs=8
-workers=8 -max_total_time=600 $PDBDUMP_CORPUS
*llvm/path/to/secondary/corpus/dir*)

--kcc

>
>
>>
>>>
>>>>
>>>> --kcc
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Sun, May 29, 2016 at 9:25 AM, David Blaikie <dblaikie at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> any chance of test cases for all this error handling being added?
>>>>>>>
>>>>>>> On Sat, May 28, 2016 at 12:45 PM, David Majnemer via llvm-commits <
>>>>>>> llvm-commits at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Author: majnemer
>>>>>>>> Date: Sat May 28 14:45:49 2016
>>>>>>>> New Revision: 271139
>>>>>>>>
>>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=271139&view=rev
>>>>>>>> Log:
>>>>>>>> [llvm-readobj] Validate the string table offset before using it
>>>>>>>>
>>>>>>>> Modified:
>>>>>>>>     llvm/trunk/tools/llvm-readobj/COFFDumper.cpp
>>>>>>>>
>>>>>>>> Modified: llvm/trunk/tools/llvm-readobj/COFFDumper.cpp
>>>>>>>> URL:
>>>>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-readobj/COFFDumper.cpp?rev=271139&r1=271138&r2=271139&view=diff
>>>>>>>>
>>>>>>>> ==============================================================================
>>>>>>>> --- llvm/trunk/tools/llvm-readobj/COFFDumper.cpp (original)
>>>>>>>> +++ llvm/trunk/tools/llvm-readobj/COFFDumper.cpp Sat May 28
>>>>>>>> 14:45:49 2016
>>>>>>>> @@ -794,14 +794,20 @@ void COFFDumper::printCodeViewSymbolSect
>>>>>>>>        while (!Contents.empty()) {
>>>>>>>>          const FrameData *FD;
>>>>>>>>          error(consumeObject(Contents, FD));
>>>>>>>> +
>>>>>>>> +        if (FD->FrameFunc >= CVStringTable.size())
>>>>>>>> +          error(object_error::parse_failed);
>>>>>>>> +
>>>>>>>> +        StringRef FrameFunc =
>>>>>>>> +
>>>>>>>> CVStringTable.drop_front(FD->FrameFunc).split('\0').first;
>>>>>>>> +
>>>>>>>>          DictScope S(W, "FrameData");
>>>>>>>>          W.printHex("RvaStart", FD->RvaStart);
>>>>>>>>          W.printHex("CodeSize", FD->CodeSize);
>>>>>>>>          W.printHex("LocalSize", FD->LocalSize);
>>>>>>>>          W.printHex("ParamsSize", FD->ParamsSize);
>>>>>>>>          W.printHex("MaxStackSize", FD->MaxStackSize);
>>>>>>>> -        W.printString("FrameFunc",
>>>>>>>> -
>>>>>>>> CVStringTable.drop_front(FD->FrameFunc).split('\0').first);
>>>>>>>> +        W.printString("FrameFunc", FrameFunc);
>>>>>>>>          W.printHex("PrologSize", FD->PrologSize);
>>>>>>>>          W.printHex("SavedRegsSize", FD->SavedRegsSize);
>>>>>>>>          W.printFlags("Flags", FD->Flags,
>>>>>>>> makeArrayRef(FrameDataFlags));
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> llvm-commits mailing list
>>>>>>>> llvm-commits at lists.llvm.org
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160531/72aebf78/attachment.html>