|
|
Subscribe / Log in / New account

stack management

stack management

Posted Aug 18, 2010 22:35 UTC (Wed) by pflugstad (subscriber, #224)
Parent article: An ancient kernel hole is closed

So, I guess I don't understand how the kernel is involved with managing the stack for user space processes? It obviously is, but what is the mechanism for it?

Hmmm... the process starts with some stack at the top of memory, which it can push/pop data from (calling to and returning from function calls). If when the process pushes more data onto the stack than is actually allocated for it (i.e. it goes over the page boundary), this will fault to the kernel, which automatically allocates more memory for it? Does that sound about right?

The bug is that if the stack runs into some already allocated heap pages, then no fault occurs (since the memory is already allocated), and so now you can write to the heap area and effectively control the stack and return addresses on it.

So, Linus' fix is to add a guard page at the bottom of the currently allocated stack? And this is causing some problems with some applications that probably pay way to much attention than they should to the stack allocation.

Seems like this would be a REALLY old problem, that up until recently was effectively impossible to exploit (due to the sizes of memory and in ability to get a remote process to actually allocate that much memory).

Separately, how are other Unixen not vulnerable to the exact same problem? If not, how do they address the problem?


to post comments

stack management

Posted Aug 18, 2010 23:14 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> And this is causing some problems with some applications that probably pay way to much attention than they should to the stack allocation.

If I read the discussion correctly, said application does not pay attention to the stack allocation in particular. Instead, it parses the information about all of its own mappings from /proc and mlock()s each one of them, instead of just using mlockall(). When the mlock() hit the guard page, it extended the stack mapping down by one page, which then confused said application when it later parsed again the mapping information from /proc (since the mappings were now different from what it had read before).

The fix was just to hide the extra guard page from /proc.

stack management

Posted Aug 21, 2010 4:32 UTC (Sat) by chad.netzer (subscriber, #4257) [Link]

The article mentions the Delalleau paper, and spender points out that it discusses a lot of the issues you raise, and has informative graphs. So check it out.

http://cansecwest.com/core05/memory_vulns_delalleau.pdf


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds