This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Possibly a bug in glibc around the getrandom(2) implementation.
I decided to start printing the rsp to the stdout, in the following way:
register unsigned long rsp asm("rsp");
printf("rsp is %p\n", (void*) rsp);
This time, it appeared that the regions are completely contained in the
stack but the stack pointer is totally out of the stack, because it's
always: 0x7ffc6fbc5700. In the dumped memory map:
7ffd21f80000-7ffd21fa1000 rw-p 00000000 00:00
0 [stack]
while the buffers are 7ffd21f9[c910-d2d0] and 7ffd21f9[c1a0-cb60]. And
even after removing the printf, the buffers are completely inside the
stack. I don't know why they previously weren't.
On the other hand, it appears that any file descriptor operation (but
not printing the rsp!! this changes nothing) magically "fixes" the bug.
I discovered it while doing `system("cat /proc/<PID>/maps")`, but it's
enough to do a successful `open` or `socket` call
Successful, that's important. Opening a nonexistent file is no fix!
I managed to attach gdb using the following trick:
register unsigned long rsp asm("rsp");
printf("rsp is %p\n", (void*) rsp);
if (n == 1) {
kill(pid, SIGSTOP);
ptrace(PTRACE_DETACH, pid, 0, 0);
}
n++;
While the std output was:
getrandom request: 0x00007fa6516d49a0 0x00007fa6516d49b8
rsp is 0x7fff6a96fd60
getrandom request: 0x00007ffe70e43e90 0x00007ffe70e44850
rsp is 0x7fff6a96fd60
the gdb reported a lower stack pointer:
rsp 0x7ffe70e436b8 0x7ffe70e436b8
It's lower than our buffer address, which is ok. Looks like something
else is smashing the stack...
On 14.07.2017 17:24, Carlos O'Donell wrote:
On 07/14/2017 11:04 AM, Marcin Mielniczuk wrote:
On the other hand, the error I'm experiencing happens only if I'm
overwriting memory with PTRACE_POKEUSER and gdb won't load a
scriptable file with a shebang. Should I simply print the RSP
register in my C utility before overwriting the buffer?
That is a good idea. Likewise you can try to reduce your problem to
something you _can_ debug, for example if you can deatch your tracer
and leave the program in a loop, then you can attach gdb and inspect
the state.