嘿，这个问题问到点子上了，刚好是内核态进程地址空间切换里容易混淆的点，我来给你掰扯清楚：

关于分配内存的地址空间归属 #

当你成功调用KeStackAttachProcess附加到目标用户态进程后，当前运行的内核线程就切换到了该用户进程的虚拟地址空间上下文。这时候你调用ZwAllocateVirtualMemory时传入的NtCurrentProcess()，其实就是你附加的那个用户进程对象——因为附加操作会把当前内核线程的“关联进程”临时改成目标用户进程。

所以你这段代码里分配的UserModeMappedAddress，100%属于目标用户态进程的虚拟地址空间。等你后续解除附加（KeUnstackDetachProcess）后，这个地址在目标用户进程里是有效的，内核态如果需要再次访问，只要重新附加就能通过该地址读写。

关于寄存器、栈等上下文的疑问 #

这里要明确一个关键区别：KeStackAttachProcess只负责切换虚拟地址空间，完全不会碰线程的执行上下文（寄存器、栈这些）。当前跑的还是你的内核回调线程（属于系统进程或者发起回调的内核线程），用的是内核栈，寄存器里的值也是这个内核线程的状态，和目标用户态进程的任何线程都没有半毛钱关系。

用户态进程的线程上下文（比如它的用户栈、寄存器快照）都存在自己的ETHREAD对象里，除非你主动调用线程切换类的API（比如KeSwitchThread，但这在这类回调场景下几乎不会用，也极不推荐），否则根本不会共享这些上下文。

给你代码的小提醒 #

你这段调用逻辑是没问题的，但有两个细节要注意：

• 分配完成后一定要记得调用KeUnstackDetachProcess解除附加，不然会导致地址空间泄漏，后续的内核操作可能跑在错误的地址空间里，踩各种奇怪的坑。
• PAGE_EXECUTE_READWRITE权限尽量谨慎用，如果你的内存不需要执行权限，换成PAGE_READWRITE更稳妥——现在系统的DEP（数据执行保护）机制会对这类权限的内存做限制，没必要给自己添麻烦。
• 回调上下文里做内存分配，一定要加异常处理（比如try/except），如果分配失败，确保没有残留的资源泄漏，毕竟回调的执行环境比较特殊，容错性很低。