[llvm-bugs] [Bug 43917] New: libFuzzer + dlopen = ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Nov 6 04:38:41 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=43917

            Bug ID: 43917
           Summary: libFuzzer + dlopen = ERROR:
                    UndefinedBehaviorSanitizer: SEGV on unknown address
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: dcoughlin at apple.com
          Reporter: rjones at redhat.com
                CC: dcoughlin at apple.com, llvm-bugs at lists.llvm.org

I'm experimenting with libFuzzer on a larger program which (in a fundamental
way that is vital to its operation) uses loadable modules.  Unfortunately when
the program is compiled with -fsanitize=fuzzer it segfaults shortly after
loading or unloading the module.  It is quite easy to reproduce this in a
simple test case, see below.

It's possible to work around this by omitting the dlclose() call (and changing
the dlopen() so it is called once) but nevertheless this seems to be a bug in
clang of some kind.  In the real program I am modifying it's not very simple to
change the code to never use dlclose.

--------------------- test.c
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <dlfcn.h>

int
LLVMFuzzerTestOneInput (const uint8_t *data, size_t size)
{
  void *dl = dlopen ("./module.so", RTLD_NOW|RTLD_GLOBAL);
  if (dl == NULL) {
    fprintf (stderr, "%s\n", dlerror ());
    exit (EXIT_FAILURE);
  }
  printf ("module loaded, dl=%p\n", dl);
  dlclose (dl);
  return 0;
}

--------------------- module.c
#include <stdio.h>

int
foo (void)
{
  return 0;
}


$ clang -g -O1 -fsanitize=fuzzer -fPIC test.c -o test
$ clang -g -O1 -fsanitize=fuzzer -fPIC -shared module.c -o module.so
$ ./test 
INFO: Seed: 2932099106
INFO: Loaded 1 modules   (3 inline 8-bit counters): 3 [0x4900a0, 0x4900a3), 
INFO: Loaded 1 PC tables (3 PCs): 3 [0x4900a8,0x4900d8), 
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than
4096 bytes
module loaded, dl=0x1c2aa20
INFO: A corpus is not provided, starting from an empty corpus
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==206642==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address
0x7f1f76a2f030 (pc 0x7f1f76610209 bp 0x7ffd075c15e0 sp 0x7ffd075c15b8 T206642)
==206642==The signal is caused by a WRITE memory access.
    #0 0x7f1f76610208 in __memset_avx2_unaligned_erms
(/lib64/libc.so.6+0x165208)
    #1 0x44525c in fuzzer::TracePC::ClearInlineCounters()
(/var/tmp/fz/test+0x44525c)
    #2 0x42aad6 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/var/tmp/fz/test+0x42aad6)
    #3 0x42b710 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long,
bool, fuzzer::InputInfo*, bool*) (/var/tmp/fz/test+0x42b710)
    #4 0x42cac0 in
fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile,
fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/var/tmp/fz/test+0x42cac0)
    #5 0x42e26c in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile,
fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/var/tmp/fz/test+0x42e26c)
    #6 0x418c1b in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
const*, unsigned long)) (/var/tmp/fz/test+0x418c1b)
    #7 0x408ba6 in main (/var/tmp/fz/test+0x408ba6)
    #8 0x7f1f764d21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    #9 0x408bfd in _start (/var/tmp/fz/test+0x408bfd)

UndefinedBehaviorSanitizer can not provide additional info.
==206642==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
0xa,
\x0a
artifact_prefix='./'; Test unit written to
./crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
Base64: Cg==

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191106/54864893/attachment-0001.html>


More information about the llvm-bugs mailing list