<html>
    <head>
      <base href="http://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - False sanitizer positive with strcmp() and strict_string_checking=1"
   href="http://bugs.llvm.org/show_bug.cgi?id=32210">32210</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>False sanitizer positive with strcmp() and strict_string_checking=1
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>new-bugs
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>3.9
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>new bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>Franz.Sirl-kernel@lauterbach.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hi,

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

#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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>