3 ms·
I seem to recall long ago there was an exploitable bug due to excessive stack use. Basically the way a kernel detects stack growth is via a guard page that cau
by asveikau 3y ago
I seem to recall long ago there was an exploitable bug due to excessive stack use.
Basically the way a kernel detects stack growth is via a guard page that causes a fault on memory access. If the allocation is bigger than the offset to the guard page, and the start of the allocation is accessed before the end, you get this. An attacker might even be able to generate a non-faulting memory access pointing at somebody else's buffer.
I think it's on the language implementation to understand what that offset might be and generate benign memory access on large stack allocations, allowing the kernel to fault and intervene. Consider it part of the ABI where you're running.
- remram 3y agoOr maybe don't allocate 20kB objects on the stack.
- leodag 3y agoWasn't that because of Variable-Length Arrays? I remember a while back there was a movement to remove all of them from the kernel.
- asveikau 3y agoPerhaps. I think there are other reasons to avoid VLAs. I've heard the code generated for them kinda sucks. But IMO a compiler should generate extra benign reads on a large stack allocation. You mention avoiding VLAs in the kernel, but even user mode code has this problem. Certainly a browser JITing random JS from the internet should be able to work around such a problem.