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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99353C433EF for ; Fri, 25 Feb 2022 04:23:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 185138D0002; Thu, 24 Feb 2022 23:23:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1346A8D0001; Thu, 24 Feb 2022 23:23:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0495B8D0002; Thu, 24 Feb 2022 23:23:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id EAD7B8D0001 for ; Thu, 24 Feb 2022 23:23:43 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A5120237EE for ; Fri, 25 Feb 2022 04:23:43 +0000 (UTC) X-FDA: 79180008726.15.0402B19 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id C772640002 for ; Fri, 25 Feb 2022 04:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rFcwgc0Y0FAbw6iDHxZlvv3kdev4RadFXvYJQwj9LlU=; b=gbSU6YfhHZwluXm/82MA9uQBPp pZYkpLtrlXbmSITGWtHG07g4IaSQMQcL0LAZ0y/AguCIRKBTCagCr5fDMeHtavg+it5VFKdYkroRP B9+L8LGl7v0mZjBTD3a7XBuGv9WGZkEFQFFYRUS1MLYHSexN3mmWa7K6o7feI+kEsS4zWhC84jaIT 6JBoy3ME02rKspj/mcvKIiAnfd6WngqPq+PjG6dc1HJq0fxAskofRqsTDsfDzNvFt5hBojNYzAeiF F4B4yZzhVm2gTDVAU0DTe82CR9WbbclPbPHTHLV/uicgN5pJ58wCxtDrNh4JnDRY4aRv2/EO5zbLT fQ3AKOfw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNS8Q-005SlC-Nw; Fri, 25 Feb 2022 04:23:14 +0000 Date: Fri, 25 Feb 2022 04:23:14 +0000 From: Matthew Wilcox To: Andrew Morton Cc: Suren Baghdasaryan , mhocko@kernel.org, mhocko@suse.com, shy828301@gmail.com, rientjes@google.com, hannes@cmpxchg.org, guro@fb.com, riel@surriel.com, minchan@kernel.org, kirill@shutemov.name, aarcange@redhat.com, brauner@kernel.org, christian@brauner.io, hch@infradead.org, oleg@redhat.com, david@redhat.com, jannh@google.com, shakeelb@google.com, luto@kernel.org, christian.brauner@ubuntu.com, fweimer@redhat.com, jengelh@inai.de, timmurray@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com, syzbot+2ccf63a4bd07cf39cab0@syzkaller.appspotmail.com, Liam Howlett Subject: Re: [PATCH 1/1] mm: fix use-after-free bug when mm->mmap is reused after being freed Message-ID: References: <20220215201922.1908156-1-surenb@google.com> <20220224201859.a38299b6c9d52cb51e6738ea@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220224201859.a38299b6c9d52cb51e6738ea@linux-foundation.org> X-Rspamd-Queue-Id: C772640002 X-Stat-Signature: ahm85g8jgmtkmsemryzwaqzq7wugie1q Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=gbSU6Yfh; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1645763022-354043 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: On Thu, Feb 24, 2022 at 08:18:59PM -0800, Andrew Morton wrote: > On Tue, 15 Feb 2022 12:19:22 -0800 Suren Baghdasaryan wrote: > > > After exit_mmap frees all vmas in the mm, mm->mmap needs to be reset, > > otherwise it points to a vma that was freed and when reused leads to > > a use-after-free bug. > > > > ... > > > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -3186,6 +3186,7 @@ void exit_mmap(struct mm_struct *mm) > > vma = remove_vma(vma); > > cond_resched(); > > } > > + mm->mmap = NULL; > > mmap_write_unlock(mm); > > vm_unacct_memory(nr_accounted); > > } > > After the Maple tree patches, mm_struct.mmap doesn't exist. So I'll > revert this fix as part of merging the maple-tree parts of linux-next. > I'll be sending this fix to Linus this week. > > All of which means that the thusly-resolved Maple tree patches might > reintroduce this use-after-free bug. I don't think so? The problem is that VMAs are (currently) part of two data structures -- the rbtree and the linked list. remove_vma() only removes VMAs from the rbtree; it doesn't set mm->mmap to NULL. With maple tree, the linked list goes away. remove_vma() removes VMAs from the maple tree. So anyone looking to iterate over all VMAs has to go and look in the maple tree for them ... and there's nothing there. But maybe I misunderstood the bug that's being solved here.