Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4527610ima; Mon, 4 Feb 2019 19:01:48 -0800 (PST) X-Google-Smtp-Source: AHgI3IYNtX++Eorx1CzrGeKoo4Xk4KEiXhLJpZEhNqle01xoLWsuTEkwq+z7sjD0eN1NCcgktuPv X-Received: by 2002:a63:c0f:: with SMTP id b15mr2492685pgl.314.1549335708685; Mon, 04 Feb 2019 19:01:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549335708; cv=none; d=google.com; s=arc-20160816; b=EHESlgoVQCNOvoiDNRECcNgEz1P0malnGHG2R1QdeCXrN5BcYv44znVXv4I7NX8gTq 5nWWOPz3N/q8NwMZw+n9+JJI3UXE0jiXQtJCCimNaDkAdYSwDuaDELnY7xcI2va4eiFd Dlank4RcdzP1qvmeUgyfY90qXhV1YnROffRr6sxUKggtfeQwFhQAOyBZU5DhHa+Xv3/g 4xp3puU384N/TmfeoJcrC1Ghtfma7sTUOPmqFKCMicjjyG39TCwzcTZeNxsx6Ue1CRod fi/tibLfOraEltwsQ8U3mF3lolB4eQHyMdrzMyNcL/Gq5vpq+TLjqtNBCk0s2s/NrEfz mBnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature; bh=KQTcnQuNEamwrMHfFUCPU7vfCyC1nyGvf7NNrOYsq6s=; b=yd4oF4dEfcpN+/WXoIE/sMDOSga9i8FMh767iY+E7g2Dj/TV2FTdYJxATUs9E4pXp2 KmG62AhEaPeC3/ox4zqwQFrKNaYCM4JBv0VJPCm9CeoajxR0bg0k61iWU0NzegJ6MitN 1fgtzcavcXYX/FotN354M9PTWmrO8dqLlBljR4csouO+RNXosUtIJ1vTBl6FPSkqI8ND Z/x2TRF3DySM3nrwo0YDsPU3CKqoBjyi/LlO0DCqGTQHi9yRjS1/8AL/1aCGleAX8o/2 Vpzi4/UF4vx/2aG9F2xn2DKEp+xc8XTYdtRISaJr2Ccy0Lc3noy51r6/KaTXn8Cqt3/s hZSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@arista.com header.s=Arista-A header.b=eSsOFQXX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=arista.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g34si1917375pld.15.2019.02.04.19.01.32; Mon, 04 Feb 2019 19:01:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@arista.com header.s=Arista-A header.b=eSsOFQXX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=arista.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727366AbfBEC77 (ORCPT + 99 others); Mon, 4 Feb 2019 21:59:59 -0500 Received: from mx.aristanetworks.com ([162.210.129.12]:46907 "EHLO prod-mx.aristanetworks.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726606AbfBEC76 (ORCPT ); Mon, 4 Feb 2019 21:59:58 -0500 X-Greylist: delayed 409 seconds by postgrey-1.27 at vger.kernel.org; Mon, 04 Feb 2019 21:59:58 EST Received: from prod-mx.aristanetworks.com (localhost [127.0.0.1]) by prod-mx.aristanetworks.com (Postfix) with ESMTP id 00ECEDF0; Mon, 4 Feb 2019 18:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=Arista-A; t=1549335189; bh=KQTcnQuNEamwrMHfFUCPU7vfCyC1nyGvf7NNrOYsq6s=; h=Date:From:To:Cc:Subject; b=eSsOFQXXFb5XzjNkN4dOHh/WBzUT0p5wwyhirABa0lMKLNaTOnTFAZY8C6LFAjHWb 3gctI0/olXPyPvDA7WHROEOAAM46L8eAJnVBDxdfTXWvVGZ6UxZ5ocqHb7Ki43ShtO fZRQuG/hiElEXUHM2EncL5es9Q4OtzX5YRUorE7Ug+s6C/Hl4AR4WRZ29THvnRNDJT qHVwASgWVoKxXkkTourkAEx90TAszhFDMSRiiqOnGFT8dO4+U1KY0dE/GTm3XkFuOs cBV9h2E1gEF4q+I+yyFBXM/KQGHQ1QJFWT77aed6CxuydduqQj6Pw5KVpc08J2CyDZ 0ZMJBstpIw+pA== Received: from visor (unknown [172.20.208.17]) by prod-mx.aristanetworks.com (Postfix) with ESMTP id E7D80DA9; Mon, 4 Feb 2019 18:53:08 -0800 (PST) Date: Mon, 4 Feb 2019 18:53:08 -0800 From: Ivan Delalande To: Andrew Morton , Al Viro Cc: Dmitry Safonov <0x7f454c46@gmail.com>, Oleg Nesterov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski Subject: [PATCH v2] exec: don't force_sigsegv processes with a pending fatal signal Message-ID: <20190205025308.GA24455@visor> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We were seeing unexplained segfaults in coreutils processes and other basic utilities on systems with print-fatal-signals enabled: [ 311.001986] potentially unexpected fatal signal 11. [ 311.001993] CPU: 3 PID: 4565 Comm: tail Tainted: P O 4.9.100.Ar-8497547.eostrunkkernel49 #1 [ 311.001995] task: ffff88021431b400 task.stack: ffffc90004cec000 [ 311.001997] RIP: 0023:[<00000000f7722c09>] [<00000000f7722c09>] 0xf7722c09 [ 311.002003] RSP: 002b:00000000ffcc8aa4 EFLAGS: 00000296 [ 311.002004] RAX: fffffffffffffff2 RBX: 0000000057efc530 RCX: 0000000057efdb68 [ 311.002006] RDX: 0000000057effb60 RSI: 0000000057efdb68 RDI: 00000000f768f000 [ 311.002007] RBP: 0000000057efc530 R08: 0000000000000000 R09: 0000000000000000 [ 311.002008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 311.002009] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 311.002011] FS: 0000000000000000(0000) GS:ffff88021e980000(0000) knlGS:0000000000000000 [ 311.002013] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 311.002014] CR2: 00000000f77bf097 CR3: 0000000150f6f000 CR4: 00000000000406f0 We tracked these crashes down to binfmt_elf failing to load segments for ld.so inside the kernel. Digging further, the actual problem seems to occur when a process gets sigkilled while it is still being loaded by the kernel. In our case when _do_page_fault goes for a retry it will return early as it first checks for fatal_signal_pending(), so load_elf_interp also returns with error and as a result search_binary_handler will force_sigsegv() which is pretty confusing as nothing actually failed here. v2: add a message when load_binary fails, add a check for fatal signals in signal_delivered (avoiding a single check in force_sigsegv as other architectures use it directly and may have different expectations). Thanks to Dmitry Safonov and Oleg Nesterov for their comments and suggestions. Fixes: 19d860a140be ("handle suicide on late failure exits in execve() in search_binary_handler()") Reference: https://lkml.org/lkml/2013/2/14/5 Signed-off-by: Ivan Delalande --- fs/exec.c | 7 ++++++- kernel/signal.c | 6 +++--- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index fb72d36f7823..caf584064f89 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1660,7 +1660,12 @@ int search_binary_handler(struct linux_binprm *bprm) if (retval < 0 && !bprm->mm) { /* we got to flush_old_exec() and failed after it */ read_unlock(&binfmt_lock); - force_sigsegv(SIGSEGV, current); + if (!fatal_signal_pending(current)) { + if (print_fatal_signals) + pr_info("load_binary() failed: %d\n", + retval); + force_sigsegv(SIGSEGV, current); + } return retval; } if (retval != -ENOEXEC || !bprm->file) { diff --git a/kernel/signal.c b/kernel/signal.c index e1d7ad8e6ab1..674076e63624 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2552,10 +2552,10 @@ static void signal_delivered(struct ksignal *ksig, int stepping) void signal_setup_done(int failed, struct ksignal *ksig, int stepping) { - if (failed) - force_sigsegv(ksig->sig, current); - else + if (!failed) signal_delivered(ksig, stepping); + else if (!fatal_signal_pending(current)) + force_sigsegv(ksig->sig, current); } /* -- 2.20.1