[openssl] OpenSSL_1_1_1-stable update

Richard Levitte levitte at openssl.org
Fri Feb 22 20:04:53 UTC 2019


The branch OpenSSL_1_1_1-stable has been updated
       via  4af54c9b9933336d1c48f3012aca92262c36d3a8 (commit)
      from  f6d64b5142ab59be47c1f10512ce6d58fb399131 (commit)


- Log -----------------------------------------------------------------
commit 4af54c9b9933336d1c48f3012aca92262c36d3a8
Author: Richard Levitte <levitte at openssl.org>
Date:   Thu Feb 21 18:25:50 2019 +0100

    Windows: Call TerminateProcess, not ExitProcess
    
    Ty Baen-Price explains:
    
    > Problem and Resolution:
    > The following lines of code make use of the Microsoft API ExitProcess:
    >
    > ```
    > Apps\Speed.c line 335:	ExitProcess(ret);
    > Ms\uplink.c line 22: ExitProcess(1);
    > ```
    >
    > These function calls are made after fatal errors are detected and
    > program termination is desired. ExitProcess(), however causes
    > _orderly_ shutdown of a process and all its threads, i.e. it unloads
    > all dlls and runs all destructors. See MSDN for details of exactly
    > what happens
    > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx).
    > The MSDN page states that ExitProcess should never be called unless
    > it is _known to be safe_ to call it. These calls should simply be
    > replaced with calls to TerminateProcess(), which is what should be
    > called for _disorderly_ shutdown.
    >
    > An example of usage:
    >
    > ```
    > TerminateProcess(GetCurrentProcess(), exitcode);
    > ```
    >
    > Effect of Problem:
    > Because of a compilation error (wrong c++ runtime), my program
    > executed the uplink.c ExitProcess() call. This caused the single
    > OpenSSL thread to start executing the destructors of all my dlls,
    > and their objects. Unfortunately, about 30 other threads were
    > happily using those objects at that time, eventually causing a
    > 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
    > best case scenario, as I'm sure you can imagine at the consequences
    > of undiscovered memory corruption, even in a terminating process.
    
    And on the subject of `TerminateProcess()` being asynchronous:
    
    > That is technically true, but I think it's probably synchronous
    > "enough" for your purposes, since a call to TerminateProcess
    > suspends execution of all threads in the target process. This means
    > it's really only asynchronous if you're calling TerminateProcess one
    > some _other_ process. If you're calling TerminateProcess on your own
    > process, you'll never return from the TerminateProcess call.
    
    Fixes #2489
    Was originally RT-4526
    
    Reviewed-by: Matt Caswell <matt at openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/8301)
    
    (cherry picked from commit 925795995018bddb053e863db8b5c52d2a9005d9)

-----------------------------------------------------------------------

Summary of changes:
 ms/uplink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ms/uplink.c b/ms/uplink.c
index 7f7abfb..2096f2c 100644
--- a/ms/uplink.c
+++ b/ms/uplink.c
@@ -28,7 +28,7 @@ static TCHAR msg[128];
 static void unimplemented(void)
 {
     OPENSSL_showfatal(sizeof(TCHAR) == sizeof(char) ? "%s\n" : "%S\n", msg);
-    ExitProcess(1);
+    TerminateProcess(GetCurrentProcess(), 1);
 }
 
 void OPENSSL_Uplink(volatile void **table, int index)


More information about the openssl-commits mailing list