I am learning about buffer overflow attacks and one thing that i am not able to understand is that in most operating systems an stack is may not necessarily be a contiguous block of memory in the physical memory. if that's true then how can an overflow overwrite the other data in stack ?

  • 2
    Physical memory does not matter since a program does not have direct access to it. It only sees a logical mapping of the physical memory. See for the concepts here. Feb 26, 2017 at 18:10
  • 1
    from what i understand by reading various articles is that this attack is based on overwriting the adjacent stack structures like return address by supplying more data then it has expected in first place. but if an stack is not contiguous then how can overflowing it with more data results in modifying the other fields that are not adjacent to it? Feb 26, 2017 at 18:19
  • 1
    The stack is contiguous from the perspective of the program which deals only with mapped (logical) memory and not the physical memory. Feb 26, 2017 at 18:25
  • i guess i am not able to express my doubt clearly.let's say for example the value of ebp and esp for stack is 0x100 and 0x96 and return address is at 0x104 so if i have to overwrite the return address then i will have to supply 12bytes of data insted of 4. but if my return address is mapped to 0x1000 in the actual physical address and esp is to 0x2000 then how can someone able to overwrite the return address with only 12 bytes of payload when the actual difference in memory for them is 1000 bytes? Feb 26, 2017 at 18:40
  • 2
    @ManvendraSingh you are not "physically" overwriting memory. Virtual to Physical memory is not even controlled by the OS, its managed by the page controller in the CPU. To the process, you are overwriting contiguous memory. That's why you can't attack one program from another, protected memory.
    – Alex
    Feb 26, 2017 at 18:53

2 Answers 2


The stack may not be physically contiguous but it is logically contiguous. If your function return pointer is logically 20 bytes or 2000 bytes above the current stack pointer then you only need to offset a write by the proper amount to smash it. The stack must always be logically contiguous to function correctly.

A much bigger problem for modern exploiters is that stack pages should be marked as non-executable. The only pages marked as executable should be the code (program) pages, and those should be marked as non-writeable. This doesn't defeat all stack overflow attacks, but it defeats the "classic" ones.


Logical to physical address mapping is done by the segmentation and paging units of the CPU. A process (which means both your program and any malicious code that gets executed in it's address space) doesn't know about this mapping; they see a continuous address space, even if that address space might not be mapped to continuous regions of physical memory by the paging unit.

Your example doesn't really work out, because page size, at least on the x86, is at least 4k. So we can't have a page boundary between 0x100 and 0x104. These addresses would map to the same physical memory, because they'd lie in the same page.

However, that doesn't matter, because even if your malicious code wrote data over a page boundary, that wouldn't magically turn off the paging unit; instead, the paging unit would translate the virtual address to the physical address of the other page.

It's really rather simple. Assuming we're dealing with 4k pages, pages start at physical addresses with the last 12 bits zeroed.

The last 12 bits of any virtual address are an offset into a page. The other bits of an address are used to identify the page in a multilayer page table, which in turn stores the physical address of the page.

A running program (and that includes any malicious code running in the same address space) can't write directly to physical adresses; any address supplied by machine instructions is considered to be a virtual address and always ends up getting translated by the segmentation and the paging unit of the cpu, so the "gap" between 0x1000 and 0x2000 that you perceive doesn't exist for the program.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .