summaryrefslogtreecommitdiffhomepage
path: root/src
diff options
context:
space:
mode:
authormidipix <writeonce@midipix.org>2016-05-10 14:01:16 -0400
committermidipix <writeonce@midipix.org>2016-05-14 07:18:24 -0400
commitf62cf86981025d5fb6f49b19db8153722c954f13 (patch)
tree3bafe335c58a78e51cd808687f7cf42aac0d27d9 /src
parent25347d2a2820f20f30c8556baef36fe6e7067a79 (diff)
downloadntapi-f62cf86981025d5fb6f49b19db8153722c954f13.tar.bz2
ntapi-f62cf86981025d5fb6f49b19db8153722c954f13.tar.xz
__ntapi_pty_connect(): added resilience.
This patch accounts for zw_map_view_of_section() returning NT_STATUS_CONFLICTING_ADDRESSES (0xC0000018) due to third-party software thread creation upon process initialization. The conflict occurs when the address of the stack that is allocated for the third-party thread happens to coincide with the internal section address which was derived from the parent. As should be noted, and while we could decide to always reset ctx->section_addr prior to mapping the internal section, the advantage of the current solution (when acocmpanied by the wrapping calls to __ntapi_log_write) consists in the indication as to whether third-party thread creation had interfered with internal process initialization routines.
Diffstat (limited to 'src')
-rw-r--r--src/pty/ntapi_pty_fd.c18
1 files changed, 17 insertions, 1 deletions
diff --git a/src/pty/ntapi_pty_fd.c b/src/pty/ntapi_pty_fd.c
index 7670c66..ea62874 100644
--- a/src/pty/ntapi_pty_fd.c
+++ b/src/pty/ntapi_pty_fd.c
@@ -9,6 +9,7 @@
#include <ntapi/nt_tty.h>
#include <ntapi/ntapi.h>
#include "ntapi_impl.h"
+#include "ntapi_log.h"
#include "ntapi_pty.h"
static int32_t __stdcall __ntapi_pty_open_close(
@@ -141,7 +142,22 @@ static int32_t __ntapi_pty_connect(
0,&ctx->section_size,
NT_VIEW_UNMAP,0,
NT_PAGE_READWRITE)))
- return __ntapi_pty_fail(ctx,status);
+ ctx->section_addr = 0;
+
+ /* resilience */
+ if (!ctx->section_addr) {
+ __ntapi_log_write("__ntapi_pty_connect:149\n",24);
+ if ((status = __ntapi->zw_map_view_of_section(
+ ctx->section,
+ NT_CURRENT_PROCESS_HANDLE,
+ &ctx->section_addr,
+ 0,ctx->section_size,
+ 0,&ctx->section_size,
+ NT_VIEW_UNMAP,0,
+ NT_PAGE_READWRITE)))
+ return __ntapi_pty_fail(ctx,status);
+ __ntapi_log_write("__ntapi_pty_connect:159\n",24);
+ }
/* assume conforming clients, config for single lock try */
__ntapi->tt_sync_block_init(&ctx->sync[__PTY_READ],0,0,1,0,0);