public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: hank <pyu@redhat.com>
To: oleg@redhat.com, tj@kernel.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 1/1] set wo_stat to an init value in do_wait function
Date: Wed, 02 Nov 2011 16:29:53 +0800	[thread overview]
Message-ID: <4EB0FF81.90808@redhat.com> (raw)

>From 23323ae46453f506df6647715042483548ea149e Mon Sep 17 00:00:00 2001
From: hank <pyu@redhat.com>
Date: Wed, 2 Nov 2011 15:28:58 +0800
Subject: [PATCH 1/1] set wo_stat to an init value in do_wait function

When all of the below conditions become true:
1 parent fork a child
2 parent ignore SIGCHLD signal
3 parent call waitpid function
do_wait function won't touch the wo->stat variable.

Below is a test program can reproduce this problem:
========================================================

int main(int argc, char *argv[])
{
        int pid, child;
        int status;
        int *p;

        signal(SIGCHLD, SIG_IGN);

        child = fork();
        if (child == 0) {
                sleep(1);
                exit(0);
        } else if (child < 0) {
                perror("fork");
                exit(1);
        } else {
                status = 0xa5a5;
                p = &status;
                printf("status addr: %p\n", p);
                pid = waitpid(-1, &status, WUNTRACED);
                printf("pid=%d status=0x%x\n", pid, status);
                exit(0);
        }
        return 0;
}
========================================================

After run this program, we can see the value of status is still
0xa5a5,so kernel do not touch this value.
It may be dangerous. Because lots of programs such as 'su' don't set
an init value for the variable 'status' when it call waitpid function,
and after the waitpid function return, the program may check the value
of 'status' to see the state of child. If kernel don't set a value to
'status', it may be a random value.
Of course, it only happens when the father program ignore SIGCHLD
signal, and the father should not ignore this signal if it want to
check the state of its child. But maybe some other programs let the
father program ignore the SIGCHLD signal. For example, the grandfather
program ignore SIGCHLD signal and it fork the father program, so the
father program ignore SIGCHLD signal...

Signed-off-by: hank <pyu@redhat.com>
---
 kernel/exit.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index d0b7d98..972f5ae 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1683,6 +1683,12 @@ static long do_wait(struct wait_opts *wo)
 
 	trace_sched_process_wait(wo->wo_pid);
 
+	if (wo->wo_stat) {
+		retval = put_user(0, wo->wo_stat);
+		if (unlikely(retval))
+			return retval;
+	}
+
 	init_waitqueue_func_entry(&wo->child_wait, child_wait_callback);
 	wo->child_wait.private = current;
 	add_wait_queue(&current->signal->wait_chldexit, &wo->child_wait);
-- 
1.7.4.4


             reply	other threads:[~2011-11-02  8:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-02  8:29 hank [this message]
2011-11-02 14:51 ` [PATCH 1/1] set wo_stat to an init value in do_wait function Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB0FF81.90808@redhat.com \
    --to=pyu@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox