From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FBB5C433EF for ; Sat, 4 Sep 2021 23:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 26BE560E73 for ; Sat, 4 Sep 2021 23:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234852AbhIDXXq (ORCPT ); Sat, 4 Sep 2021 19:23:46 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:45184 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233054AbhIDXXp (ORCPT ); Sat, 4 Sep 2021 19:23:45 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mMevT-0019im-JH; Sat, 04 Sep 2021 23:18:19 +0000 Date: Sat, 4 Sep 2021 23:18:19 +0000 From: Al Viro To: Linus Torvalds Cc: Oleg Nesterov , Kyle Huey , Kees Cook , Andrew Morton , Dmitry Vyukov , linux-kernel@vger.kernel.org Subject: [RFC] another signal oddity Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Suppose we are sending e.g. SIGINT to a process (by kill(2)). The target has two threads - * thread1 (leader) that has SIGINT blocked * thread2 that does *not* have SIGINT blocked * thread2 is ptraced and running (not in ptrace stop). * handler for SIGINT is SIG_DFL. complete_signal() is called. want_signal(SIGINT, thread1) is false. type is not PIDTYPE_PID and thread_group_empty() is false. want_signal(SIGINT, thread2) is true, so we end up with signal->curr_target and t set to thread2. p is thread1. And then we hit this: if (sig_fatal(p, sig) && True - the handler is SIG_DFL and unhandled SIGINT is fatal !(signal->flags & SIGNAL_GROUP_EXIT) && True - we are not in group exit. !sigismember(&t->real_blocked, sig) && True - nobody is in sigtimedwait(), so ->real_blocked is empty. (sig == SIGKILL || !p->ptrace)) { Also true - thread1 is not ptraced. So we go ahead and initiate a group exit. Both thread1 and thread2 get SIGKILL added to ->blocked and are woken up. But AFAICS we have no business doing that - thread1 has SIGINT blocked, so get_signal() in it would not pick that SIGINT. And thread2 is traced, so picking SIGINT would've hit ptrace_signal(), stop and let the tracer deal with it. If the tracer decides to cancel that SIGINT, we would continue just fine. Which order of execution could possibly lead to fatal signal delivery? IDGI... Looks like that !p->ptrace used to be !t->ptrace until 426915796cca "kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in complete_signal()" back in 2017, but I don't see anything in commit message that would explain that part of changes. The testcase in there wouldn't care either way... What am I missing here?