Possibly a bug in glibc around the getrandom(2) implementation.

[Marcin Mielniczuk]

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.
>