linux-kernel - Re: CLONE_VM: parent terminates silently when child segfaults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Feb 2010 16:01:34 +0800
From:	Américo Wang <xiyou.wangcong@...il.com>
To:	Frank Heckenbach <f.heckenbach@...soft.de>
Cc:	linux-kernel@...r.kernel.org, oleg@...hat.com
Subject: Re: CLONE_VM: parent terminates silently when child segfaults

On Thu, Jan 28, 2010 at 4:48 AM, Frank Heckenbach
<f.heckenbach@...soft.de> wrote:
> When a process cloned with CLONE_VM is killed by SIGSEGV, the parent
> process is terminated silently. I don't know if this is known or
> intended behaviour, but I didn't find anything about it.
>
> The test program below demonstrates the problem. It forks a process
> which in turn clones another process which kills itself with
> SIGSEGV.
>
> When I remove the CLONE_VM flag, the program runs as expected:
>
>  fork_pid = ...
>  clone_pid = ...
>  (1 second delay)
>  cloned process status = 11
>  forked process status = 0
>
> However, with CLONE_VM I get:
>
>  fork_pid = ...
>  clone_pid = ...
>  (1 second delay)
>  forked process status = 0
>
> i.e., no output from the first forked process after its waitpid(),
> and no error indication in its status as seen by the main process.
>
> Note: The fork() before clone() is not essential to cause this
> behaviour, just to see its effects (in the 2nd waitpid()). You can
> see the same by calling the program without fork from the shell and
> looking at $?. I just put in fork to make sure it's not a shell
> problem or something.
>
> The problem only occurs with signals such as SIGSEGV or SIGILL, not
> with SIGINT, SIGUSR1, etc. Since CLONE_VM and SIGSEGV both have to
> do with the shared memory space, I'd understand if the parent
> process was also killed by SIGSEGV or so. But having it return with
> status 0 seems strange -- how is one supposed to detect a SIGSEGV in
> the child? The parent can't do it when it's terminated, and the
> parent's parent only sees it terminate with 0.

I think this behavior is somewhat expected.

Becase SIGSEGV and SIGILL are coredump signals, when you use CLONE_VM,
child process will share the memory space with its parent, what would
you expect the parent behaves when its child coredumping their shared memory
space?

Also, you may want to check CLONE_THREAD too, it also provides a chance
of leaving the status of child unavailable.

Cc'ing signal experts...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/