linux-kernel - [PATCH 24/26] signal: In ptrace_stop improve identical signal detection

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:   Tue,  6 Jun 2017 14:03:36 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     linux-kernel@...r.kernel.org
Cc:     linux-api@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kees Cook <keescook@...omium.org>,
        Roland McGrath <roland@...k.frob.com>,
        Al Viro <viro@...IV.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: [PATCH 24/26] signal: In ptrace_stop improve identical signal detection

When two signals are generated make it the thread level signal that is
possibly surpessed.  The reasoning is that the group level signal
always needs to be generated to report a group stop when that happens
and it is possibly doing double duty as both the group level and the
thread level signal.  So if the thread level signal is identical to
the group level signal it does not need to be sent (or even attempted
to be sent).

Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
---
 kernel/signal.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 0ec90689039a..ff41e6ee2b5e 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1813,6 +1813,7 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
 	__acquires(&current->sighand->siglock)
 {
 	bool gstop_done = false;
+	bool identical = false;
 
 	if (arch_ptrace_stop_needed(exit_code, info)) {
 		/*
@@ -1852,8 +1853,16 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
 	 * could be clear now.  We act as if SIGCONT is received after
 	 * TASK_TRACED is entered - ignore it.
 	 */
-	if (why == CLD_STOPPED && (current->jobctl & JOBCTL_STOP_PENDING))
-		gstop_done = task_participate_group_stop(current);
+	if (why == CLD_STOPPED) {
+		if (current->jobctl & JOBCTL_STOP_PENDING)
+			gstop_done = task_participate_group_stop(current);
+
+		/* Will the two generated signals be identical? */
+		identical = gstop_done &&
+			!(current->jobctl & JOBCTL_TRAP_NOTIFY) &&
+			!ptrace_reparented(current) &&
+			(task_pid(current) == task_tgid(current));
+	}
 
 	/* any trap clears pending STOP trap, STOP trap clears NOTIFY */
 	task_clear_jobctl_pending(current, JOBCTL_TRAP_STOP);
@@ -1874,10 +1883,11 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
 		 * know about every stop while the real parent is only
 		 * interested in the completion of group stop.  The states
 		 * for the two don't interact with each other.  Notify
-		 * separately unless they're gonna be duplicates.
+		 * separately unless they are going to be identical.
 		 */
-		do_notify_parent_cldstop(current, true, why);
-		if (gstop_done && ptrace_reparented(current))
+		if (!identical)
+			do_notify_parent_cldstop(current, true, why);
+		if (gstop_done)
 			do_notify_parent_cldstop(current, false, why);
 
 		/*
-- 
2.10.1