[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211101034147.6203-3-khuey@kylehuey.com>
Date: Sun, 31 Oct 2021 20:41:47 -0700
From: Kyle Huey <me@...ehuey.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>,
Jens Axboe <axboe@...nel.dk>,
Peter Zijlstra <peterz@...radead.org>,
Marco Elver <elver@...gle.com>,
Oleg Nesterov <oleg@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Collingbourne <pcc@...gle.com>,
Alexey Gladkov <legion@...nel.org>
Cc: Robert O'Callahan <rocallahan@...il.com>,
Marko Mäkelä <marko.makela@...iadb.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH 2/2] signal: after notifying a ptracer of a signal, recheck for pending SIGKILLs
ptrace_signal will release the siglock which could result in the current
task catching a SIGKILL that was not present on our first check in
get_signal. If that happens, bail out of the current signal and go
straight to the SIGKILL. This avoids setting up a frame for a signal
that the ptracer may not be notified of but that will be visible at
PTRACE_EVENT_EXIT.
Signed-off-by: Kyle Huey <khuey@...ehuey.com>
Reported-by: Marko Mäkelä <marko.makela@...iadb.com>
---
kernel/signal.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 4d26ee5c662a..09810777c61b 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2738,6 +2738,13 @@ bool get_signal(struct ksignal *ksig)
signr = ptrace_signal(signr, &ksig->info);
if (!signr)
continue;
+ /*
+ * After calling the debugger anything could have changed.
+ * If there's a pending SIGKILL stop processing the current
+ * signal and skip straight to the end.
+ */
+ if (signal_group_exit(signal))
+ goto kill;
}
ka = &sighand->action[signr-1];
--
2.33.1
Powered by blists - more mailing lists