This C program snippet as follows intends to copy some memory, say 1,024 bytes, using the usual memcpy(3) glibc API, from a source location 300 KB into the program to a destination location 400 KB into the program. As Application 1 is the program at the low end of physical memory (see the preceding memory map), it starts at the 0x0 physical offset.

First, let's see the correct usage case.

Refer to the following pseudocode:

phy_offset = 0x0;
src = phy_offset + (300*1024);       /* = 0x0004 b000 */
dest = phy_offset + (400*1024);      /* = 0x0006 4000 */
n = 1024;
memcpy(dest, src, n);

The effect of the preceding code is shown in the following diagram:

As can be seen in the preceding diagram, this works! The (big) arrow shows the copy path from source to destination, for 1,024 bytes. Great.

Now for the buggy case.

All remains the same, except that this time, due to a bug (or malicious intent), the dest pointer is modified as follows:

phy_offset = 0x0;
src = phy_offset + (300*1024);       /* = 0x0004 b000 */
dest = phy_offset + (400*1024*156);  /* = 0x03cf 0000 !BUG! */
n = 1024;
memcpy(dest, src, n);

The destination location is now around 64 KB (0x03cf0000 – 0x03d00000) into the operating system! The best part: the code itself does not fail. memcpy() does its job. Of course, now the OS is probably corrupted and the entire system will (eventually) crash.

Note that the intent here is not to debug the cause (we know); the intent here is to clearly realize that, in spite of this bug, memcpy succeeds.
How come? This is because we are programming in C – we are free to read and write physical memory as we wish; inadvertent bugs are our problem, not the language's!

So what now? Ah, this is one of the key reasons why VM systems came into existence.