After buf = malloc(1) with full page heap, why is the guard page exception not thrown until buf[16] is being overwritten?

Question

1. Code in a bug

   int main()
   {
       void *ptr = 0;    
       int overrun = 1;
       ptr = malloc(overrun);
       while(overrun++)
       {
           if(!ptr)
               while(1) Sleep(500);
           *((char*)ptr + (overrun+1)) = 'a';
           printf("\n%d\n",overrun);
       }
       return 0;
   }
   

2. From project menu of visual studio 2010 made sure the build is "Release" and "x64" (machine is x64)

3. Enable FULL PAGE HEAP

   gflags /p /enable test.exe /full
   

4. Make windbg default debugger

   E:\installed\Debugging Tools for Windows (x64)>windbg -I
   

5. Run the code as separate exe from cmd without debugger

   Output:

   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   

   after which windbg is seen catching the corruption. And I thought full page heap is suppose to catch corruptions instantly.

   Any comments as to why full page heap sucks?

Answer 1

Since heap allocations are required to be aligned, an overrun that does not cross an alignment boundary cannot be caught at the time the overrun occurs because memory protection is page-granular, not byte-granular. This is a hardware limitation. The overrun will be detected when you free the memory and the tail bytes are checked for tampering.

(By the way, saying that something sucks makes it less likely the person you accused of sucking is going to bother to help you with your problem. Just a tip.)

Answer 2

To expand on Raymond's response. If you look in the debugger at the original pointer returned via malloc you will see that it is 16 bytes from the end of the page. This is because the HeapAlloc alignment requirement on x64 is 16-bytes. So it placed the 1 byte you asked for as close as it could to the end of the page. Once you walk off the end of the page you fault.