Stack resident buffer overflow on 64-bit?

Question

I\'m studying some security related things and right now I\'m playing around with my own stack. What I\'m doing should be very trivial, I\'m not even trying to execute the s

Answer 1

The answers given by "kch" and "import os.boom.headshot" are not quite correct.

What is actually happening is that the value on the stack (0x4141414141414141) which is to be popped into RIP by the RET instruction contains an address which is in the 'non-canonical' address range of the processor. This causes the CPU to generate a general protection fault (GPF) interrupt rather than a fault generated by a kernel pre-check. The GPF in turn triggers the kernel to report a segmentation fault before RIP is actually updated and that is what you're seeing in GDB.

Most modern CPUs only provide a 48-bit address range which is split between a higher and lower half which occupy the address ranges 0x0000000000000000 to 0x00007FFFFFFFFFFF and 0xFFFF800000000 to 0xFFFFFFFFFFFFFFFF respectively. See this wikipedia link for further information.

If the address had been outside the non-canonical range (0x00008FFFFFFFFFFF to 0xFFFF7FFFFFFFFFFF) then RIP would have been updated as expected. Of course, a subsequent fault may have been generated by the kernel if the new address was invalid for any other reason (i.e. outside the process's address range).