Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2907084ybk; Mon, 18 May 2020 10:49:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLZCAu8fMfzODEOZDPt/KhX2fzDbCZGzlndUU7vxi2geWL/aKmDaxpmkFD9wLcqAxFGxpX X-Received: by 2002:a50:fd97:: with SMTP id o23mr14712402edt.363.1589824193405; Mon, 18 May 2020 10:49:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589824193; cv=none; d=google.com; s=arc-20160816; b=X9Z+dxbL3ppCULrzssbs/Mc7KzayIAPV9ibbm53Kf7Wws1ydyNz9nBcMS+NswE7k99 zw7Td/DTajxMSXJ5mm6Av3KYfeZMmsJ4JNeWWli6t3Q58Oejm2Zz+ftQXc8ctcLB1mjO yeP5Jld53W8kkHCQX6/YBw+KwL5An7uUmzBrD/wCdAmn8Q4GWhJgZYjdU8EmHquliBt3 AKW+KSxc/fSiRF9EHiEDsBur1MrtT7gXs3gqp7Beu6Zi7U6Oy2U5jl6EE51KKNStPND1 8G4ZbWTYQrUh0aNw/1mENYkXBKcEzmGOYj6uFi99cB56KvEkxyRN4BD2O4z72orihgWQ N5Xw== 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=4Nm0D+k+V1FyUzSDMytzoYO7RUdyNUNGjn7VKWJvVS0=; b=NwiyqR0lmEzupQ0966ud8mww0aoRzPGN7uw6ISRFEz3kY9KoWcHa5FjG5WiYk54ick JP0lUZyRsOUbK+VBG/+gTwhPIdGkomJSxmBJ2H/5v4kuifdgw8j2P2SxKb0sKjPUUM23 4SDz2OI/ifPHnPTros14g7kMDT8DI0TCOlWQnuRIlqQo9Z8/6xxBETkyVZWCvrjKUOKK 0ZMdX3wIdJd2H7dRxuY5LvYMN/yYyQ3I2oI1gtH/m9lp/5OH5LgW/tq5kblphAXPDlwY G0pOeyhjvYspMo61H2xY3Xj/OTUhaevJ8IPBGAZunBKWnhWWbIZgixB5Y2TT90APg3oF a6JA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mWs+Xln5; 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 u12si6915443ejz.22.2020.05.18.10.49.30; Mon, 18 May 2020 10:49:53 -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=mWs+Xln5; 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 S1729358AbgERRpF (ORCPT + 99 others); Mon, 18 May 2020 13:45:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:43518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729829AbgERRo6 (ORCPT ); Mon, 18 May 2020 13:44:58 -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 7D19920657; Mon, 18 May 2020 17:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589823897; bh=Kr0RiHN8SqbbMMjfNPM6EqrkZ89tVDlgdXlRto14bHo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mWs+Xln5paCYKzBzp3TZDGJ0MtLNveUKR9S/RdtThvJMl4v0h8UlyjgSe6Q+IGxMv aFMLtU0QwrGpnurD/1gBSbFjCnjQXj90N9PGfC4eQy1+8FwPObz0GsDI1e0TQMqnGJ KjhOODs2RxvYaqcu5DVGaVPuAoNMYj/+OMz9Kydo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Eric W. Biederman" Subject: [PATCH 4.9 81/90] exec: Move would_dump into flush_old_exec Date: Mon, 18 May 2020 19:36:59 +0200 Message-Id: <20200518173507.703925788@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200518173450.930655662@linuxfoundation.org> References: <20200518173450.930655662@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 @@ -1270,6 +1270,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 */ @@ -1780,8 +1782,6 @@ static int do_execveat_common(int fd, st if (retval < 0) goto out; - would_dump(bprm, bprm->file); - retval = exec_binprm(bprm); if (retval < 0) goto out;