Thread: How to detect if a pointer points to invalid memory? (Win32)

> Now how can I be sure that the memory it allocated can be read?
In what circumstances would you expect this to be ever false?

Unless you have access to kernel memory data structures, the only way to actually know if a memory address is valid is to attempt to access the memory and see if it fails. This, of course, should be done in a block protected by relevant exception handling, or you haven't got a chance to survive. [actually, you only need to check each first byte of every even 4KB region, since that's the granularity of the memory allocations].

The way that the kernel COULD validate memory is by walking over the page-table entries relevant to that address - however, if the successrate of "just attempting access the memory" is relatively high (it's likely that you've been given a valid memory location) then "try and see" is an option.

--
Mats

The article is correct - if you arbitrarily check ALL kinds of pointers with IsBadXXXPtr then you could cause more problems than you will fix. You should not check stack-addresses with IsBadXXXPtr [1].

Which goes back to Salem's question: What are you actually trying to "fix"? If your app is using some DLL that has a function that returns a pointer to some memory, it is a broken implementation if you can't read that memory. The next question is of course if you and the DLL agree on the size and usage of that memory - but the DLL is fundamentally broken if it doesn't return a valid memory address when that is what's expected of it.

[1] Since the stack is ALWAYS readable and writable by your application, that should cause no problem. The next problem is of course to determine if an address is within the stack. The following code shows how you can do that:

Code:

char *baseStackPtr;
void initStackCheck(void *p)
{
   baseStackPtr = p;
}

int isStackPtr(void *p)
{
    char dummy;
    char *topOfStack = &dummy;
    char *cp = p;
    
    if (cp > baseStackPtr && cp < topOfStack) 
      return 1;
    return 0;
}

int main()
{
    int x;  // Any local variabe in main will do. 
    initStackCheck(&x);
    ....
     // your code goes here.
    
    return 0;
}

Also, you will only hit a stack guardpage if you are using a negative offset off the current stack position, since the stack grows towards zero - so the code is most likely broken in some bad way in the first place, if you hit that problem - because it means you are using some piece of memory that you don't currently own!

--
Mats

> A virtual memory address can be unmapped at any point when inside the function:
But if it is unmapped, the process will be asleep at that point and the page will be in the swap file. When the process next runs, the illegal memory reference will be trapped by the OS to restore the page and then allow the process to continue.

If it started out valid when you allocated it, it will remain so until you free it.

Originally Posted by Elysia

About the second... about the stack page guard.
I don't know much about it, but since when do you pass a stack address to the function? That's stupid. A pointer to an object on the stack is always gauranteed to be valid since the stack doesn't delete objects.
So then again... you pass a stack object by pointer to a function. Then what? Since a stack object cannot be destroyed (data only re-written; correct me someone if I'm wrong), then there's no point in checking. Sure, so they can pass an invalid address, but does that point to the stack?
Also, other threads can't modify stack objects since each thread gets their own stack, so I find those points kind of moot.

It is quite common to pass a stack based address to a funciton - every time you use the address of a local variable, in fact, which is a fairly common thing - at least I do that quite often. [However, if we are talking of something returned from another function, it'd better NOT be a stack address UNLESS it's also been passed in by the calling code, and it's BELOW [a higher address than] the current stack pointer].

Stack objects can not be destroyed BELOW your point on the stack, that is correct.

Other threads can [but shouldn't] modify stuff on your stack, since all threads share the same memory mappings, and all stacks are shared within the task/process.

--
Mats

Originally Posted by Salem

> A virtual memory address can be unmapped at any point when inside the function:
But if it is unmapped, the process will be asleep at that point and the page will be in the swap file. When the process next runs, the illegal memory reference will be trapped by the OS to restore the page and then allow the process to continue.

If it started out valid when you allocated it, it will remain so until you free it.

I think this refers to a case where something is UNMAPPED, not "swapped out", so the memory is no longer valid. And this is only done [intentionally] by malicious code, and much more a problem when using kernel code than when using user-mode code.

--
Mats

Originally Posted by --article--

The only thing that IsBadReadPtr/IsBadWritePtr verifies is that at the instant that the API is called, there was valid memory at that location. There’s nothing to prevent another thread in the application from unmapping the virtual address passed into IsBadReadPtr immediately after the call is made.

In simple language: a machine checking if food is poisoned is totally useless, because it doesn't stop anyone from injecting poison into the food after it is checked by the machine... lol.

Originally Posted by maxorator

In simple language: a machine checking if food is poisoned is totally useless, because it doesn't stop anyone from injecting poison into the food after it is checked by the machine... lol.

Good analogy!

--
Mats

Yes, crashing when malicious code is run is definitely not a bad thing.

Note also that "unmapped" in this context means not just free'd/delete'd, but that the memory has been "removed from the virtual space of that application". It can be done, for example if you delete the heap, or you map and unmap using VirtualAlloc and friends, but it's not your typical code.

--
Mats