Why doesn't Valgrind memcheck catch this UB?

Question

Like the title say I really need help of understanding, why this code is treated on my system ( linux mint 19, GCC-8.0.1, valgrind-3.13.0, c17 ) as NOT valid code:

#include <stdio.h>
#include <string.h>

void printThis( const char *const ptr );

int main( void) {

    char a[10] = "asds";
    char b[10] = "1234567890";

    strcpy ( a, b );
    printThis( a );
}

void printThis( const char *const ptr ){
    printf("Copy completed! : %s\n", ptr );
}

Valgrind reports the problem here:

==6973== Memcheck, a memory error detector
==6973== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6973== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6973== Command: /home/michi/Templates/Cprogram/bin/Debug/Cprogram
==6973== 
==6973== Source and destination overlap in strcpy(0x1ffefffd14, 0x1ffefffd1e)
==6973==    at 0x4C32E97: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6973==    by 0x108724: main (main.c:12)
==6973== 
Copy completed! : 1234567890
==6973== 
==6973== HEAP SUMMARY:
==6973==     in use at exit: 0 bytes in 0 blocks
==6973==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==6973== 
==6973== All heap blocks were freed -- no leaks are possible
==6973== 
==6973== For counts of detected and suppressed errors, rerun with: -v
==6973== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

and this one as Valid code:

#include <stdio.h>

void strcpy2(char *s, char *t);
void printThis( const char *const ptr );

int main( void) {

    char a[10] = "asds";
    char b[10] = "1234567890";

    strcpy2( a, b );
    printThis( a );
}

void strcpy2(char *s, char *t) {
    while ( ( *(s++) = *(t++) ) );
}

void printThis( const char *const ptr ){
    printf("Copy completed! : %s\n", ptr );
}

Valgrind output:

==7025== Memcheck, a memory error detector
==7025== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7025== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==7025== Command: /home/michi/Templates/Cprogram/bin/Debug/Cprogram
==7025== 
Copy completed! : 1234567890
==7025== 
==7025== HEAP SUMMARY:
==7025==     in use at exit: 0 bytes in 0 blocks
==7025==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==7025== 
==7025== All heap blocks were freed -- no leaks are possible
==7025== 
==7025== For counts of detected and suppressed errors, rerun with: -v
==7025== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Compiled with O0, O1, O2 and O3 and GCC flags:

-Wpedantic -std=c17 -Wall -Wextra -Werror -Wstrict-prototypes -Wmissing-prototypes -Wmisleading-indentation -Wduplicated-cond -Wold-style-definition -Wconversion -Wshadow -Winit-self -Wfloat-equal -Wwrite-strings -O0 -g

with "not valid code", are you referring to the message "Source and destination overlap in strcpy"? — Karsten Koop, Sep 18 '18 at 14:30
I undid my downvote. You could make your question more clear by clearly stating the question: ***"Why doesn't valgrind catch this UB?"*** — HolyBlackCat, Sep 18 '18 at 14:32
I removed the part with `strcpy`, which makes the Question dificult — Michi, Sep 18 '18 at 14:32
If this is not a SO Question, than probably I should delete my Account here.# — Michi, Sep 18 '18 at 14:34
Your question was unclear at first. With @HolyBlackCat's comment it makes more sense now. — 001, Sep 18 '18 at 14:35
@Michi and I rolled back the question because there is nothing interesting in valgrind *not* spotting a bug. — Antti Haapala -- Слава Україні, Sep 18 '18 at 14:35
It's a valid question. Though IMO the wording is slightly unclear. At the first glance it seemed like "I use UB, but my code works properly, why?" question, which newbies ask a lot. — HolyBlackCat, Sep 18 '18 at 14:35
I removed the `strcpy2` from the first excerpt - it wasn't used there — Antti Haapala -- Слава Україні, Sep 18 '18 at 14:54

Antti Haapala -- Слава Україні · Accepted Answer · 2018-09-18T14:39:22.753

4

Valgrind can catch only certain kinds of errors. It cannot instrument the stack, hence it would not see the error with your strcpy2. OTOH the strcpy is replaced by a version that does check if the source and destination overlap - it could catch this only because a + 10 == b in your compiled program!

To catch this kind of error use GCC's -fsanitize=address:

% ./a.out 
=================================================================
==3368==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff13832a2a at pc 0x557f05344da8 bp 0x7fff13832990 sp 0x7fff13832980
READ of size 1 at 0x7fff13832a2a thread T0
    #0 0x557f05344da7 in strcpy2 (/a.out+0xda7)
    #1 0x557f05344cca in main (/a.out+0xcca)
    #2 0x7f2d400e5b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #3 0x557f05344a49 in _start (/a.out+0xa49)

Address 0x7fff13832a2a is located in stack of thread T0 at offset 106 in frame
    #0 0x557f05344b39 in main (/a.out+0xb39)

  This frame has 2 object(s):
    [32, 42) 'a'
    [96, 106) 'b' <== Memory access at offset 106 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
[ ... many more lines follow ... ]

edited Sep 18 '18 at 14:39

answered Sep 18 '18 at 14:34

Antti Haapala -- Слава Україні

129,958
22
279
321

I can not use `-fsanitize=address` because I get [THIS](https://pastebin.com/raw/1jnqVkqH) – Michi Sep 18 '18 at 14:44
Strange indeed :D – Antti Haapala -- Слава Україні Sep 18 '18 at 14:47
1

@Michi Try adding `-lasan` to linker flags. – HolyBlackCat Sep 18 '18 at 14:50
1

@Michi ah, I compiled it with one command only - you should add `-fsanitize=address` to the linking `gcc` too – Antti Haapala -- Слава Україні Sep 18 '18 at 14:53
I think I am doing something wrong here because I get `ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.` – Michi Sep 18 '18 at 14:58
Instead works fine with `-static-libasan`. I think, [because I get This](https://pastebin.com/raw/ux23PAnP) – Michi Sep 18 '18 at 15:00
The asan doesn't need valgrind – Antti Haapala -- Слава Україні Sep 18 '18 at 15:44

score 0 · Answer 2 · answered Sep 18 '18 at 16:08

I've updated the title to be more accurate concerning the Valgrind tool used.

Valgrind can detect this sort of error, but as already noted, not with memcheck.

If I run this example code with Valgrind exp-sgcheck (exp = experimental, sgcheck = stack and globals check)

valgrind --tool=exp-sgcheck ./so19

Then I get

==25056== Invalid read of size 1
==25056== at 0x40059D: strcpy2 (so19.c:23)
==25056== by 0x400564: main (so19.c:18)
==25056== Address 0x1ffeffed1a expected vs actual:
==25056== Expected: stack array "b" of size 10 in frame 1 back from here

==25056== Actual: unknown
==25056== Actual: is 0 after Expected
==25056==
==25056== Invalid write of size 1
==25056== at 0x4005A0: strcpy2 (so19.c:23)
==25056== by 0x400564: main (so19.c:18)
==25056== Address 0x1ffeffed2a expected vs actual:
==25056== Expected: stack array "a" of size 10 in frame 1 back from here

==25056== Actual: unknown
==25056== Actual: is 0 after Expected
==25056==
==25056== Invalid read of size 1
==25056== at 0x4005A2: strcpy2 (so19.c:23)
==25056== by 0x400564: main (so19.c:18)
==25056== Address 0x1ffeffed2a expected vs actual:
==25056== Expected: stack array "a" of size 10 in frame 1 back from here

==25056== Actual: unknown
==25056== Actual: is 0 after Expected
==25056==
==25056== Invalid read of size 1
==25056== at 0x4E74C9C: vfprintf (in /lib64/libc-2.12.so)
==25056== by 0x4E7BFF9: printf (in /lib64/libc-2.12.so)
==25056== by 0x4005CD: printThis (so19.c:27)
==25056== by 0x400570: main (so19.c:19)
==25056== Address 0x1ffeffed2a expected vs actual:
==25056== Expected: stack array "a" of size 10 in frame 3 back from here

==25056== Actual: unknown
==25056== Actual: is 0 after Expected
==25056==
==25056== Invalid read of size 1
==25056== at 0x4E9E7C0: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)

==25056== by 0x4E74FFF: vfprintf (in /lib64/libc-2.12.so)
==25056== by 0x4E7BFF9: printf (in /lib64/libc-2.12.so)
==25056== by 0x4005CD: printThis (so19.c:27)
==25056== by 0x400570: main (so19.c:19)
==25056== Address 0x1ffeffed2a expected vs actual:
==25056== Expected: stack array "a" of size 10 in frame 4 back from here

==25056== Actual: unknown
==25056== Actual: is 0 after Expected

This is when compiled with debug information (-g). With an optimized build no errors are detected.

Why doesn't Valgrind memcheck catch this UB?

2 Answers2