From patchwork Wed Sep 30 01:20:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jann Horn X-Patchwork-Id: 11807521 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A0972112E for ; Wed, 30 Sep 2020 01:20:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EB6C212CC for ; Wed, 30 Sep 2020 01:20:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dABZmGqS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EB6C212CC Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 24D926B0068; Tue, 29 Sep 2020 21:20:05 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id DAAF36B0070; Tue, 29 Sep 2020 21:20:04 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADD6C6B006C; Tue, 29 Sep 2020 21:20:04 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id 805AC6B006E for ; Tue, 29 Sep 2020 21:20:04 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 405CF52A6 for ; Wed, 30 Sep 2020 01:20:04 +0000 (UTC) X-FDA: 77317971528.28.bells41_5d004e12718e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 1C74D6C04 for ; Wed, 30 Sep 2020 01:20:04 +0000 (UTC) X-Spam-Summary: 1,0,0,e31100ec298f70be,d41d8cd98f00b204,jannh@google.com,,RULES_HIT:41:152:355:379:541:800:960:973:988:989:1260:1277:1313:1314:1345:1359:1437:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2691:2731:2901:3138:3139:3140:3141:3142:3152:3353:3865:3867:3868:3870:3871:3872:3874:4250:4321:5007:6261:6653:7903:7974:10004:10400:11026:11658:11914:12296:12297:12438:12519:12555:12663:12895:13069:13311:13357:14096:14097:14181:14394:14659:14721:21080:21324:21444:21627:21795:21990:30054:30070:30090,0,RBL:209.85.218.65:@google.com:.lbl8.mailshell.net-62.18.0.100 66.100.201.100;04y8sy7q38ujh839sp7rs7gqtazfaopmhxe5gc3pnqxwacrgzuk3ddf3z517j3f.fuqh8455jizwa459tnggug4xmd7cbrdwqu97d8zfgxhjthoopjx85umbmoo4wyb.q-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: bells41_5d004e12718e X-Filterd-Recvd-Size: 4477 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Sep 2020 01:20:03 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id z23so328301ejr.13 for ; Tue, 29 Sep 2020 18:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SkYLlbk/QVyeZ8H3h2WamWGpJNG0N9vY2AmCSYNYmgU=; b=dABZmGqSFzz1GK4Q+V0hn9ld2fPMleDQjezgEMJkJZGD62P+xTxnTxGDANGDc8C7o9 jCDXXcQF3qaIm5Y8OwGDyksok9iMW7PNCeObEsV9rwTdf/iV/EgW0Cc7GicAAKCGPL8X yTYkh65gsS6D+G0kp+x5azhPTg+ETy8ESTyvoelAvBCwyWMx+Von5HWD7x8r8ju90oRt RqwGrk59E9vqEs0m3xifUjjCzsVLRrGHdbYx6wA0qsepY7QsERrTvWfvzEvmsfSTStxJ 8p+fusYhMs3Khus78/5Z9j/RVbI6W8V88/bHj0h8BauS3PkQJsA4YoFr/InVEZ04NaBe lKbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SkYLlbk/QVyeZ8H3h2WamWGpJNG0N9vY2AmCSYNYmgU=; b=rKAJcsdpdG+txhZlr0IXyVTR9ziXzq6hwOnrHMN00d++qKMP9sy9K6+K9Ym/zhoc8B vIhVWA6e7pvbh7UnNTRVCYw/zBY+JL4n1sMqqnZlhYK4RG7BJB8dGoNXmG0iPduOVBtI J7gOhoPFES0wISzgXPFAxuOzir0L+08PzwBDjQ3aSm9lZJqoKZMQY/GWD3kY0JGxkEqB IPbE8NZlBHJTTh9xtoT0TSYFIwHDFhWga8njjsf8dkucjHJMmoCQ7KrBTwyioSBHbxmM rXLISic2Ij5TmaVRVtb+wjymdyW+C/ZLsZw00DTbuG4Gi9o6pmZ2YcamzWVptpSDe7yv SiqQ== X-Gm-Message-State: AOAM533ZuCOjqGmUsTi3gON4ZhDd5e21Wwsz+q01miGVqIGElJuDyBTE +7+4g+p6LkVYWKF3eB4IIJAJoFIohyA/ZfujCQeV6TD1I9E= X-Google-Smtp-Source: ABdhPJyIzeDgcumibpF4LXHJo9wpiZYhqcK1auU45s2iksKYX+f5p+9ffbvzpcy8gSwTcSNY0TW02yvSdMOFR9CbRJA= X-Received: by 2002:a17:906:9389:: with SMTP id l9mr382229ejx.537.1601428802195; Tue, 29 Sep 2020 18:20:02 -0700 (PDT) Received: from 913411032810 named unknown by gmailapi.google.com with HTTPREST; Tue, 29 Sep 2020 18:20:00 -0700 From: Jann Horn X-Mailer: git-send-email 2.28.0.709.gb0816b6eb0-goog In-Reply-To: <20200930011944.19869-1-jannh@google.com> References: <20200930011944.19869-1-jannh@google.com> MIME-Version: 1.0 Date: Tue, 29 Sep 2020 18:20:00 -0700 Message-ID: Subject: [PATCH 2/4] binfmt_elf: Take the mmap lock around find_extend_vma() To: Andrew Morton , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, "Eric W . Biederman" , Michel Lespinasse , Mauro Carvalho Chehab , Sakari Ailus X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: create_elf_tables() runs after setup_new_exec(), so other tasks can already access our new mm and do things like process_madvise() on it. (At the time I'm writing this commit, process_madvise() is not in mainline yet, but has been in akpm's tree for some time.) While I believe that there are currently no APIs that would actually allow another process to mess up our VMA tree (process_madvise() is limited to MADV_COLD and MADV_PAGEOUT, and uring and userfaultfd cannot reach an mm under which no syscalls have been executed yet), this seems like an accident waiting to happen. Let's make sure that we always take the mmap lock around GUP paths as long as another process might be able to see the mm. (Yes, this diff looks suspicious because we drop the lock before doing anything with `vma`, but that's because we actually don't do anything with it apart from the NULL check.) Signed-off-by: Jann Horn Acked-by: Michel Lespinasse --- fs/binfmt_elf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 40ec0b9b4b4f..cd7c574a91a4 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -309,7 +309,10 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec, * Grow the stack manually; some architectures have a limit on how * far ahead a user-space access may be in order to grow the stack. */ + if (mmap_read_lock_killable(mm)) + return -EINTR; vma = find_extend_vma(mm, bprm->p); + mmap_read_unlock(mm); if (!vma) return -EFAULT;