Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2974272ybk; Mon, 18 May 2020 12:31:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyw94iSrOLERChYywIJr+U7vOh4+an7HNolvJ+dpRAL3QqSfsdAd70ER7g+lU+CjeRKTRt8 X-Received: by 2002:a17:906:da1e:: with SMTP id fi30mr15757015ejb.80.1589830291910; Mon, 18 May 2020 12:31:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589830291; cv=none; d=google.com; s=arc-20160816; b=owuYHzgCogrw0lS2Fn7RqcaprTigncsMG4AbvsE8eNpEmLaFENhGV0AlOm8O1PMbZ2 N9pq55ptXvnBUxKlNJyHwSp3JPPdhqpOuDQ4b9BH2mll4Sdxc4N4z+NyrqVlRqgDbxJT X44lH7DT3hrbJEFaX24EJKf2cPo5MSzthJeMkuS7UMgeXnzG17heUHY5sVv2WoGR6gNM t+phWrKAi54Kt5nyNOKte7lGRG8OLPBtGxdns3BLWYx/ekqFitQ58tMW+kJn2uILx7Og ZHE3uw1bGgyWdmbIFrwk5Q7VDOJ8vBQHlHK86VDDQ5xFcyB4gmYfOzok0ZfF+BWYI/kh Z+dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=uW6R6RHGkGWaHLdPqbIJnuffBJ61N2ZC11USw+ZcMv4=; b=WrIRQpMofJGZKRzwKKVnyQPnE5XhPxB/iJYaVOkknpw+WP6Q4Z2eIh0xkOGqGFFXxG cSo9Rw9PLA/zkS2kdlLP0WN4K2A6EixR77BIHQu7BHbHDcZlytb0K9w1LJiHvk3ORTWP tWdNW6Pgoqfnhf8SArylOiap1E1hdPapqFEgasH0lAvvuhI+qjE/MkqdiGxJazEbLH6h y5Gufpb6NLdHd5Wp6Ob+WsbPr5svkNS1jIhmo2Vl0pLZcVrrknvr1PbTQmQj1vmR7630 /TR6WrUeBBgKWRNndqMw3kPnd4lAxhJ5Ppow9PzZDImYKL8cw0ALLgKWyZR4DVDoR/zD Xr7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Fa0Slpgv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w19si4228295edx.164.2020.05.18.12.31.09; Mon, 18 May 2020 12:31:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Fa0Slpgv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732135AbgERR7w (ORCPT + 99 others); Mon, 18 May 2020 13:59:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:40632 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732117AbgERR7r (ORCPT ); Mon, 18 May 2020 13:59:47 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5470C20829; Mon, 18 May 2020 17:59:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589824786; bh=MFX1D15+H6M6gUGFxg0qxvMGealBsCwkAo68PBUZB9I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fa0SlpgvXEb03jYXsKDOpHzd5L+FkFmTYIk2FAdsHQ1EVHLb9mbYC6mQElpXUwQQA 6UOixfXcDZsL1ZRjgmCyjoJbFnoxbHYM4inhuwyrv23a3VfNAYaw2F/7EWB5RqdAsC Wgt4p5b21iXXnbXtcXGv7Gj5wmk7ifAI82xg6ma0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Eric W. Biederman" Subject: [PATCH 5.4 123/147] exec: Move would_dump into flush_old_exec Date: Mon, 18 May 2020 19:37:26 +0200 Message-Id: <20200518173528.245364334@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200518173513.009514388@linuxfoundation.org> References: <20200518173513.009514388@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric W. Biederman commit f87d1c9559164294040e58f5e3b74a162bf7c6e8 upstream. I goofed when I added mm->user_ns support to would_dump. I missed the fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and binfmt_script bprm->file is reassigned. Which made the move of would_dump from setup_new_exec to __do_execve_file before exec_binprm incorrect as it can result in would_dump running on the script instead of the interpreter of the script. The net result is that the code stopped making unreadable interpreters undumpable. Which allows them to be ptraced and written to disk without special permissions. Oops. The move was necessary because the call in set_new_exec was after bprm->mm was no longer valid. To correct this mistake move the misplaced would_dump from __do_execve_file into flos_old_exec, before exec_mmap is called. I tested and confirmed that without this fix I can attach with gdb to a script with an unreadable interpreter, and with this fix I can not. Cc: stable@vger.kernel.org Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman --- fs/exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/exec.c +++ b/fs/exec.c @@ -1274,6 +1274,8 @@ int flush_old_exec(struct linux_binprm * */ set_mm_exe_file(bprm->mm, bprm->file); + would_dump(bprm, bprm->file); + /* * Release all of the old mmap stuff */ @@ -1817,8 +1819,6 @@ static int __do_execve_file(int fd, stru if (retval < 0) goto out; - would_dump(bprm, bprm->file); - retval = exec_binprm(bprm); if (retval < 0) goto out;