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=-9.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 6D9E1C83000 for ; Tue, 28 Apr 2020 18:26:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4295F208E0 for ; Tue, 28 Apr 2020 18:26:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588098362; bh=Fbzklwso61IMLOubYjfCEIBGHAuX+p6DKbIr5DOMRtA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=PSTq18Js9V+Ovth5cxdzunEqJ6iSZ38jfRGhqc6XRarl03X63h3HfH97fFd4cxhdQ 8aSwTiV36/28LmOHbpNtOp9nYLlD2mXceEL8awNJb+dX/cpGikCe6bz6PNAOt9RV7H 2bBKdWXxnBCAixiHFwfTuQEhdplYkYjboH6eVrfU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728526AbgD1S0B (ORCPT ); Tue, 28 Apr 2020 14:26:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:37236 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727827AbgD1S0B (ORCPT ); Tue, 28 Apr 2020 14:26:01 -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 C631620730; Tue, 28 Apr 2020 18:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588098361; bh=Fbzklwso61IMLOubYjfCEIBGHAuX+p6DKbIr5DOMRtA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2ihNLzPULseabd9+RtGvpec0vwhk0S2WW5iQXod52pIxgc6h6l714lXQiGHQIGpRX gdkt94BX9iPQMIyi/Gr8je7lsB1a61GNRpnj3tAXHaJFjb8PfYcgL0YB8GRArkf7qE hxa1CnRclEcrzcBVOMDKgUKYbmZ17AMNFZadHMzM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jens Axboe , Linus Torvalds , Sasha Levin , Jann Horn Subject: [PATCH 5.6 001/167] mm: check that mm is still valid in madvise() Date: Tue, 28 Apr 2020 20:22:57 +0200 Message-Id: <20200428182225.685927310@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200428182225.451225420@linuxfoundation.org> References: <20200428182225.451225420@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Linus Torvalds [ Upstream commit bc0c4d1e176eeb614dc8734fc3ace34292771f11 ] IORING_OP_MADVISE can end up basically doing mprotect() on the VM of another process, which means that it can race with our crazy core dump handling which accesses the VM state without holding the mmap_sem (because it incorrectly thinks that it is the final user). This is clearly a core dumping problem, but we've never fixed it the right way, and instead have the notion of "check that the mm is still ok" using mmget_still_valid() after getting the mmap_sem for writing in any situation where we're not the original VM thread. See commit 04f5866e41fb ("coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping") for more background on this whole mmget_still_valid() thing. You might want to have a barf bag handy when you do. We're discussing just fixing this properly in the only remaining core dumping routines. But even if we do that, let's make do_madvise() do the right thing, and then when we fix core dumping, we can remove all these mmget_still_valid() checks. Reported-and-tested-by: Jann Horn Fixes: c1ca757bd6f4 ("io_uring: add IORING_OP_MADVISE") Acked-by: Jens Axboe Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/madvise.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/mm/madvise.c b/mm/madvise.c index 4bb30ed6c8d21..8cbd8c1bfe159 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -27,6 +27,7 @@ #include #include #include +#include #include @@ -1090,6 +1091,23 @@ int do_madvise(unsigned long start, size_t len_in, int behavior) if (write) { if (down_write_killable(¤t->mm->mmap_sem)) return -EINTR; + + /* + * We may have stolen the mm from another process + * that is undergoing core dumping. + * + * Right now that's io_ring, in the future it may + * be remote process management and not "current" + * at all. + * + * We need to fix core dumping to not do this, + * but for now we have the mmget_still_valid() + * model. + */ + if (!mmget_still_valid(current->mm)) { + up_write(¤t->mm->mmap_sem); + return -EINTR; + } } else { down_read(¤t->mm->mmap_sem); } -- 2.20.1