From patchwork Fri Jan 8 08:41:25 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: William Breathitt Gray X-Patchwork-Id: 1423687 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DBxRD0wJWz9sWs; Fri, 8 Jan 2021 19:41:42 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kxnKz-0000KE-5G; Fri, 08 Jan 2021 08:41:37 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kxnKx-0000Ji-F9 for kernel-team@lists.ubuntu.com; Fri, 08 Jan 2021 08:41:35 +0000 Received: from mail-vk1-f197.google.com ([209.85.221.197]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kxnKx-00062K-5Q for kernel-team@lists.ubuntu.com; Fri, 08 Jan 2021 08:41:35 +0000 Received: by mail-vk1-f197.google.com with SMTP id k187so5181201vka.7 for ; Fri, 08 Jan 2021 00:41:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OhAfcNHy/qRLjGDuNjikFJKSuofrGIdkZkUxdt9pqIo=; b=BIVOEy+DlnzhgwxJklPdyXHNylJ2sD/p6jvsutPNMaS3sDuTOt2Od8cI1i8RlyzwSj j3RLkApx8TczreSEEu0k7Dy7FodYaVlrJPmxmaMe3VT6vs2zMmNEYqEb6QZ7q46zS1jB QT2J9kDTUJcBpvv2dLdBDYe8za6MxYkqTtmOIT19fEaqOx2ThrJvDP3/MPDBGU1Mw/92 CPBo6O4c5S34lEJ5tmm2sJgokoaHryX5Asnmd25FMbDoFBtWNYTBaHJ3C71U3X967nlt D28IE4phBE+JcUYnUctNWjlWda7V3q/UJ7A90Zlaz76Ba5dF/ax7e8IoX1SHy+QMBzYA xHcw== X-Gm-Message-State: AOAM532gqgs4PbZrRrdEAlR/rVEfJrdQfj+n51/AodHUbMXZl1eFWdQ2 cBiKroa9mKRXyUfPAU1vdGkdV+LJguJ3P/9/DOETGWqYD2Z3IaZOtlMYoNHg+LdLjInLI9XEHfS 9T5qDqqO+IMGVq+P05fQUpbM9BivoeecZQEywORM5dw== X-Received: by 2002:a05:6102:2:: with SMTP id j2mr1976062vsp.47.1610095294060; Fri, 08 Jan 2021 00:41:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJzitTmDnzTsR7U4YR+8/mmnsxIQCCTborMVcYKdGmk5uezgclZ0BDS0b8zGtppAAv2rq2NudQ== X-Received: by 2002:a05:6102:2:: with SMTP id j2mr1976051vsp.47.1610095293861; Fri, 08 Jan 2021 00:41:33 -0800 (PST) Received: from localhost.localdomain ([193.27.12.132]) by smtp.gmail.com with ESMTPSA id q63sm194242vkg.43.2021.01.08.00.41.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jan 2021 00:41:33 -0800 (PST) From: William Breathitt Gray To: kernel-team@lists.ubuntu.com Subject: [SRU][CVE-2020-29372][X][PATCH 1/1] mm: check that mm is still valid in madvise() Date: Fri, 8 Jan 2021 03:41:25 -0500 Message-Id: <20210108084126.6804-2-william.gray@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210108084126.6804-1-william.gray@canonical.com> References: <20210108084126.6804-1-william.gray@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Linus Torvalds 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 CVE-2020-29372 (backported from commit bc0c4d1e176eeb614dc8734fc3ace34292771f11) [ vilhelmgray: include linux/sched.h instead of linux/sched/mm.h ] Signed-off-by: William Breathitt Gray --- mm/madvise.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/mm/madvise.c b/mm/madvise.c index f548c66154ee..cf2b217a647a 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -20,6 +20,7 @@ #include #include #include +#include /* * Any behaviour which results in changes to the vma->vm_flags needs to @@ -491,6 +492,23 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) write = madvise_need_mmap_write(behavior); if (write) down_write(¤t->mm->mmap_sem); + + /* + * 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);