From f62cf86981025d5fb6f49b19db8153722c954f13 Mon Sep 17 00:00:00 2001
From: midipix <writeonce@midipix.org>
Date: May 14 2016 11:18:24 +0000
Subject: __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.

---

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);