cve-2017-17052: Avoid unsafe exits in threads

According to manpage exit(3) calling exit is not thread-safe.
And with glibc 2.28 (and probably also with glibc >=2.27) sometimes
child processes created in fork_thread can get stuck on process exit in
glibc's __run_exit_handlers trying to acquire some lock which was in
locked state while the fork was created. This can happen when exit is
called in mmap_thread concurrently to the fork.
While the main process will still return with PASSED some of its
children are left behind.

Comparing the source code with the original program as described in the
commit 2b7e8665b4ff51c034c55df3cff76518d1a9ee3a of linux kernel >=4.13
the exits in mmap_thread and fork_thread should not be necessary to
trigger the original bug.

Therefore those exit calls are removed. The mmap_thread and fork_thread
should still exit when their corresponding main thread in do_test_fork
calls exit_group. The remaining exit in do_test_fork will be called in
the main thread without any concurrent thread in the same process.

Signed-off-by: Mathias Fiedler <mathias.fiedler@aox-tech.de>
Acked-by: Cyril Hrubis <chrubis@suse.cz>
Acked-by: Jan Stancek <jstancek@redhat.com>

testcases/cve/cve-2017-17052.c

@@ -46,18 +46,13 @@ static void *mmap_thread(void *arg)
 	for (;;) {
 		SAFE_MMAP(NULL, 0x1000000, PROT_READ,
 				MAP_POPULATE|MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
-		if (*do_exit)
-			exit(0);
 	}
 
 	return arg;
 }
 
 static void *fork_thread(void *arg)
 {
-	if (*do_exit)
-		exit(0);
-
 	usleep(rand() % 10000);
 	SAFE_FORK();