All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Emelyanov <xemul@openvz.org>,
	Roland McGrath <roland@redhat.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] protect /sbin/init from unwanted signals more
Date: Tue, 18 Nov 2008 18:59:01 +0100	[thread overview]
Message-ID: <20081118175901.GA17134@redhat.com> (raw)

init ignores the SIG_DFL signals but we queue them anyway, including
SIGKILL. This is mostly OK, the signal will be dropped silently when
dequeued, but the pending SIGKILL has 2 bad implications:

	- it implies fatal_signal_pending(), so we confuse things
	  like wait_for_completion_killable/lock_page_killable.

	- for the sub-namespace inits, the pending SIGKILL can
	  mask (legacy_queue) the subsequent SIGKILL from the
	  parent namespace which must kill cinit reliably.
	  (preparation, cinits don't have SIGNAL_UNKILLABLE yet)

The patch can't help when init is ptraced, but ptracing of init is
not "safe" anyway.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>

--- K-IS/kernel/signal.c~1_INIT_IGN_KILL	2008-11-10 19:21:17.000000000 +0100
+++ K-IS/kernel/signal.c	2008-11-17 19:54:09.000000000 +0100
@@ -43,7 +43,13 @@ static struct kmem_cache *sigqueue_cache
 
 static void __user *sig_handler(struct task_struct *t, int sig)
 {
-	return t->sighand->action[sig - 1].sa.sa_handler;
+	void __user *h = t->sighand->action[sig - 1].sa.sa_handler;
+
+	/* drop SIGKILL early to not confuse wait_xxx_killable/etc */
+	if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) && h == SIG_DFL)
+		h = SIG_IGN;
+
+	return h;
 }
 
 static int sig_handler_ignored(void __user *handler, int sig)


             reply	other threads:[~2008-11-18 16:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18 17:59 Oleg Nesterov [this message]
2008-11-19 18:51 ` [PATCH 1/2] protect /sbin/init from unwanted signals more Roland McGrath
2008-11-20  2:00   ` Eric W. Biederman
2008-11-20  3:04     ` Roland McGrath
2008-11-20 14:52     ` Oleg Nesterov
2008-11-20 18:10       ` Eric W. Biederman
2008-11-20 20:00         ` Oleg Nesterov
2008-11-20 20:28           ` [PATCH] processes: reparent_thread: don't call kill_orphaned_pgrp() if task_detached() Oleg Nesterov
2008-11-26 20:21             ` Roland McGrath
2008-12-04 17:14               ` Oleg Nesterov
2008-12-04  1:06             ` Roland McGrath
2008-11-20 15:20   ` [PATCH 1/2] protect /sbin/init from unwanted signals more Oleg Nesterov
2008-11-20 21:24     ` 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=20081118175901.GA17134@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=serue@us.ibm.com \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=xemul@openvz.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.