[llvm-bugs] [Bug 32210] New: False sanitizer positive with strcmp() and strict_string_checking=1

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32210

            Bug ID: 32210
           Summary: False sanitizer positive with strcmp() and
                    strict_string_checking=1
           Product: new-bugs
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: Franz.Sirl-kernel at lauterbach.com
                CC: llvm-bugs at lists.llvm.org

Hi,

the problem shows with a slight variation of
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/test/asan/TestCases/strcmp_strict.c?view=markup
:

#include <assert.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv) {
  size_t size = 100;
  char fill = 'o';
  char *s1 = (char*)malloc(size);
  memset(s1, fill, size);
  char *s2 = (char*)malloc(size);
  memset(s2, fill, size);
  s1[size - 1] = 'z';
  s2[size - 1] = '\0'; /* <-- changed from 'x' to '\0' */
  int r = strcmp(s1, s2);
  assert(r == 1);
  free(s1);
  free(s2);
  return 0;
}

This results in:
# clang -fsanitize=address strcmp_strict2.c -g -O1
# ASAN_OPTIONS=strict_string_checks=1 ./a.out 
=================================================================
==24632==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60b00000aff4 at pc 0x000000426fc0 bp 0x7ffe3fb8dbb0 sp 0x7ffe3fb8d340
READ of size 101 at 0x60b00000aff4 thread T0
    #0 0x426fbf in __interceptor_strcmp
/home/abuild/rpmbuild/BUILD/llvm-3.9.1.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:283:3
    #1 0x4e72ad in main /home/fsirl/strcmp_strict2.c:14:11
    #2 0x7f192b8786e4 in __libc_start_main
/usr/src/debug/glibc-2.22/csu/libc-start.c:289
    #3 0x41b808 in _start
/home/abuild/rpmbuild/BUILD/glibc-2.22/csu/../sysdeps/x86_64/start.S:118

0x60b00000aff4 is located 0 bytes to the right of 100-byte region
[0x60b00000af90,0x60b00000aff4)
allocated by thread T0 here:
    #0 0x4b9f3c in __interceptor_malloc
/home/abuild/rpmbuild/BUILD/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
    #1 0x4e723d in main /home/fsirl/strcmp_strict2.c:8:21

SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/abuild/rpmbuild/BUILD/llvm-3.9.1.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:283:3
in __interceptor_strcmp
Shadow bytes around the buggy address:
  0x0c167fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00
  0x0c167fff95e0: 00 00 00 00 00 00 00 00 04 fa fa fa fa fa fa fa
=>0x0c167fff95f0: fa fa 00 00 00 00 00 00 00 00 00 00 00 00[04]fa
  0x0c167fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff9640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==24632==ABORTING


I believe this is a false positive, because I'm pretty sure that every sane
strcmp() implementation will stop the compare when *s1 or *s2 are '\0' and thus
never overrun the other (potentially non-terminated) string.
This causes quite a few reports in our code base and at every occurence so far
we know for sure it's a false positive.
If this super-strict checking with strcmp() was really intended, I would
suggest to move it to a higher level, like strict_string_checks=2.

-- 
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/20170310/2ef16071/attachment.html>