Many viruses and especially worms aimed at Windows do their dirt by exploiting buffer overruns. Typically an application that has more authority than it needs, does something like strcpy(dst, src); where dst is a fixed size block on the stack, or on the heap, and src is a C string in some data packet copied from someplace outside the application, perhaps ultimately via the Internet. There is probably some standard saying that the length of the string at src should be less than the size that the application allocated for dst. Whoever ultimately produced the data at src had another plan, however. There are no zero bytes at src until after a packet of machine code which strcpy dutifully copies onto the stack. Shortly after the routine with the strcpy returns, which it does by retrieving the return address from the stack where the routine put it just after it was called. But guess what; where the return address used to be was written over by the strcpy and the new value points to the machine language code that strcpy moved onto the stack. Whoever crafted the packet now has code that he produced running with the full (and excessive) authority of the application.

In response to this class of software flaw, Intel allocated a new bit in the page table entry that instructs the CPU to not fetch instructions from such a page. The stack is now normally mapped with such page table entries unless the application code is designed to fetch instructions from the stack. This logic is called DEP in MS Windows. Here is why some routines with nested functions need to execute code on the stack. Actually it is only programs with call sites where the called function is either a pointer to a function, or a parameter which is a function, and that function is nested. There are many and common patterns where calls of nested functions do not execute stack code but Xcode seems to disable this protection feature in those cases as well.