https://bugs.kde.org/show_bug.cgi?id=514094

            Bug ID: 514094
           Summary: readlink("/proc/self/exe") overwrites buffer beyond
                    its return value
    Classification: Developer tools
           Product: valgrind
      Version First 3.26.0
       Reported In:
          Platform: Debian stable
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

SUMMARY

On Debian 13, the following C program behaves differently under valgrind vs not
under valgrind:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
int main() {
    char buf[64];
    memset(buf, 0, 64);
    int ret = readlink("/proc/self/exe", buf, 64);
    printf("ret = %d, buf = %.64s\n", ret, buf);
    return 0;
}

STEPS TO REPRODUCE
1. Compile the program: `cc foo.c`
2. Run without valgrind: `./a.out`
3. Run with valgrind: `valgrind ./a.out`

OBSERVED RESULT

Without valgrind: `ret = 17, buf = /home/akuli/a.out`

With valgrind: `ret = 17, buf = /home/akuli/a.outrind/memcheck-amd64-linux`

Return value 17 is correct, but the rest of the buffer is overwritten by the
string `/usr/libexec/valgrind/memcheck-amd64-linux`.

EXPECTED RESULT

Always `ret = 17, buf = /home/akuli/a.out`

SOFTWARE/OS VERSIONS
Debian 13
Valgrind 3.24.0
Valgrind 3.26.0

ADDITIONAL INFORMATION

This is not specific to memcheck: adding `--tool=none` gives me `ret = 17, buf
= /home/akuli/a.outrind/none-amd64-linux`.

I tried with valgrind 3.24.0 from apt and 3.26.0 compiled from source
(valgrind.org), same behavior.

I think this used to work in some version of valgrind, because I got this
problem when valgrinding after I upgraded to a newer Debian.

This only happens with `/proc/self/exe`. If I use another symlink, it works
fine.

`strace ./a.out` gives `readlink("/proc/self/exe", "/home/akuli/a.out", 64)`.

This can be worked around with `buf[ret] = '\0'` or by placing the program to a
directory with a long name.

This is not a compiler problem, because this happens with gcc and with LLVM.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to