[Bug libc/20422] New: do not allow asan/msan/tsan and fortify at the same time.

["konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20422

            Bug ID: 20422
           Summary: do not allow asan/msan/tsan and fortify at the same
                    time.
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: konstantin.s.serebryany at gmail dot com
                CC: drepper.fsp at gmail dot com, fweimer at redhat dot com,
                    hanno at hboeck dot de
  Target Milestone: ---

When fortify is used with msan it will cause msan false positives. 

#include <stdio.h>
#include <string.h>
int main()
{
        char text[100];
        sprintf(text, "hello");
        printf("%lu\n", strlen(text));
}

% clang test.c -fsanitize=memory   -O3 && ./a.out 
5
% clang test.c -fsanitize=memory -D_FORTIFY_SOURCE=2  -O3 && ./a.out 
Uninitialized bytes in __interceptor_strlen at offset 0 inside [0x7ffe259e4d20,
6)
==26297==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4869cc in main 

With asan, this will not cause false positives, but may case false negatives. 

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char *T = "hello";
volatile int sink;
int main(int argc, char **argv)
{
        int n = argc == 1 ? 4 : atoi(argv[1]);
        char *text = (char*)malloc(n);
        sprintf(text, "%s", T);
        sink = text[1];
        free(text);
}

% clang asan-test.c -fsanitize=address   -O3  && ./a.out 2>&1 | grep ERROR
==27843==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000fbf4 at pc 0x0000004a7cb0 bp 0x7ffe22795bc0 sp 0x7ffe22795370
% clang asan-test.c -fsanitize=address   -O3 -D_FORTIFY_SOURCE=2 && ./a.out
2>&1 | grep ERROR 
%

same with tsan. 

This is happening because fortify replaces libc functions (e.g. sprintf)
with its own variants (__sprintf_chk) and the sanitizers don't know about these
variants. 

supporting fortify in *san makes little sense because fortify does not add
anything to the sanitizers and it will only increase the complexity. 

So, the better way is to warn the user that the sanitizers and fortify are
incompatible. 

Florian suggested that the simplest way to warn is to modify the glibc headers
to check if fortify and one of the sanitizers is enabled. 

Note that gcc and clang use different ways to tell that a sanitizer is on
(macros in gcc, __has_feature in clang)

-- 
You are receiving this mail because:
You are on the CC list for the bug.