fix: manual stack manipulation in sleaping()

[ccoskrnl]

PAGE BOUNDARY CHECK (Manual Stack Extension Fix)

Problem Description

In the x64 calling convention, the first four arguments are passed via registers (RCX, RDX, R8, R9), while arguments 5 and 6 must be placed on the stack at RSP+40 (0x28) and RSP+48 (0x30).

A critical issue arises when the RSP (Stack Pointer) is located near the upper boundary of a committed memory page. For example, if RSP is 0x3C2E8FFFF8, calculating RSP + 40 results in 0x3C2E900000. This new address crosses into the subsequent virtual memory page.

Under normal execution, the CPU hardware and Windows kernel manage stack growth automatically using Guard Pages. When a standard push instruction or a function's prologue hits a Guard Page, the OS intercepts the fault and commits more memory. However, when we perform manual stack manipulation (via direct pointer dereferencing), we bypass this mechanism. If the target address (RSP + 40) resides in a page that is still marked as MEM_RESERVE or is a PAGE_GUARD that hasn't been officially tripped by the OS, the CPU cannot perform the write operation. This results in an immediate EXCEPTION_ACCESS_VIOLATION (C0000005).

Solution

To ensure stability during manual thread context manipulation, we implement a Page Boundary Check. Before attempting to write arguments to the stack, the code calculates whether the target addresses (RSP + 40 or RSP + 48) reside on a different memory page than the current RSP.

If a page crossing is detected, we proactively call the AllocateStack function. This function ensures the target memory region is transitioned from a RESERVED or GUARD state to a fully COMMITTED state with PAGE_READWRITE permissions. By manually "backing" the virtual address with physical memory before the write occurs, we prevent the access violation and ensure the hijacked thread can resume execution safely.