All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	jolsa@redhat.com, Namhyung Kim <namhyung@kernel.org>,
	luca abeni <luca.abeni@santannapisa.it>,
	syzkaller <syzkaller@googlegroups.com>,
	Oleg Nesterov <oleg@redhat.com>
Subject: [PATCH 1/2] signal: Always notice exiting tasks
Date: Thu, 07 Feb 2019 00:43:33 -0600	[thread overview]
Message-ID: <87zhr8rtd6.fsf_-_@xmission.com> (raw)
In-Reply-To: <875ztwt7yy.fsf_-_@xmission.com> (Eric W. Biederman's message of "Thu, 07 Feb 2019 00:42:45 -0600")


Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 kernel/signal.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9ca8e5278c8e..5424cb0006bc 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
 		goto relock;
 	}
 
+	/* Has this task already been marked for death? */
+	ksig->info.si_signo = signr = SIGKILL;
+	if (signal_group_exit(signal))
+		goto fatal;
+
 	for (;;) {
 		struct k_sigaction *ka;
 
@@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
 			continue;
 		}
 
+	fatal:
 		spin_unlock_irq(&sighand->siglock);
 
 		/*
-- 
2.17.1


  reply	other threads:[~2019-02-07  6:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01 16:48 perf_event_open+clone = unkillable process Dmitry Vyukov
2019-02-01 17:06 ` Dmitry Vyukov
2019-02-02 18:30   ` Jiri Olsa
2019-02-03 15:21     ` Jiri Olsa
2019-02-04  9:27   ` Thomas Gleixner
2019-02-04  9:38     ` Dmitry Vyukov
2019-02-04 17:38       ` Thomas Gleixner
2019-02-05  3:00         ` Eric W. Biederman
2019-02-05  4:27           ` Eric W. Biederman
2019-02-05  6:07             ` Eric W. Biederman
2019-02-05 15:26               ` [RFC][PATCH] signal: Store pending signal exit in tsk.jobctl not in tsk.pending Eric W. Biederman
2019-02-06 12:09                 ` Dmitry Vyukov
2019-02-06 21:47                   ` Eric W. Biederman
2019-02-06 18:07                 ` Oleg Nesterov
2019-02-06 22:25                   ` Eric W. Biederman
2019-02-07  6:42                     ` [PATCH 0/2]: Fixing unkillable processes caused by SIGHUP timers Eric W. Biederman
2019-02-07  6:43                       ` Eric W. Biederman [this message]
2019-02-11 14:13                         ` [PATCH 1/2] signal: Always notice exiting tasks Oleg Nesterov
2019-02-12  0:42                           ` Eric W. Biederman
2019-02-12  8:18                             ` Eric W. Biederman
2019-02-12 16:50                               ` Oleg Nesterov
2019-02-13  3:58                                 ` Eric W. Biederman
2019-02-13  4:09                                 ` [PATCH] signal: Restore the stop PTRACE_EVENT_EXIT Eric W. Biederman
2019-02-13 13:55                                   ` Oleg Nesterov
2019-02-13 14:38                                   ` Oleg Nesterov
2019-02-13 14:58                                     ` Eric W. Biederman
2019-02-07  6:44                       ` [PATCH 2/2] signal: Better detection of synchronous signals Eric W. Biederman
2019-02-11 15:18                         ` Oleg Nesterov
2019-02-12  0:01                           ` Eric W. Biederman
2019-02-12 17:21                             ` Oleg Nesterov
2019-02-07 11:46                       ` [PATCH 0/2]: Fixing unkillable processes caused by SIGHUP timers Dmitry Vyukov

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=87zhr8rtd6.fsf_-_@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=syzkaller@googlegroups.com \
    --cc=tglx@linutronix.de \
    /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.