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=-6.5 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 626E1C43461 for ; Sun, 13 Sep 2020 11:16:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8883621548 for ; Sun, 13 Sep 2020 11:16:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8883621548 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D78686B0002; Sun, 13 Sep 2020 07:16:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2B246B0037; Sun, 13 Sep 2020 07:16:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C40F56B0055; Sun, 13 Sep 2020 07:16:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id ADC936B0002 for ; Sun, 13 Sep 2020 07:16:33 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6790A833F2E8 for ; Sun, 13 Sep 2020 11:16:33 +0000 (UTC) X-FDA: 77257785066.22.boy21_300efb6270ff Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 47EB3181960A5 for ; Sun, 13 Sep 2020 11:16:33 +0000 (UTC) X-HE-Tag: boy21_300efb6270ff X-Filterd-Recvd-Size: 3026 Received: from r3-23.sinamail.sina.com.cn (r3-23.sinamail.sina.com.cn [202.108.3.23]) by imf37.hostedemail.com (Postfix) with SMTP for ; Sun, 13 Sep 2020 11:16:31 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([123.115.166.229]) by sina.com with ESMTP id 5F5DFF8A000206BB; Sun, 13 Sep 2020 19:16:28 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 66715054919417 From: Hillf Danton To: linmiaohe Cc: Hillf Danton , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "syzkaller-bugs@googlegroups.com" , syzbot Subject: Re: general protection fault in unlink_file_vma Date: Sun, 13 Sep 2020 19:16:16 +0800 Message-Id: <20200913111616.3700-1-hdanton@sina.com> In-Reply-To: References: MIME-Version: 1.0 X-Rspamd-Queue-Id: 47EB3181960A5 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.001094, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 13 Sep 2020 09:17:26 +0000 linmiaohe wrote: >=20 > I reviewed the code carefully these days and I found vma_merge() do onl= y fput() the vm_file of the linked vma in remove_next cases. > This gpf is much likely because the ->mmap() callback can change vma->v= m_file and fput the original file. But my previous commit > failed to catch this case and always fput() the original file, hence ad= d an extra fput(). > The below patch would make the things right: >=20 > diff --git a/mm/mmap.c b/mm/mmap.c > index 080f44bcf7a8..80ea11bf12fa 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1816,7 +1816,11 @@ unsigned long mmap_region(struct file *file, uns= igned long addr, > merge =3D vma_merge(mm, prev, vma->vm_start, vm= a->vm_end, vma->vm_flags, > NULL, vma->vm_file, vma->vm_pgoff, NULL= , NULL_VM_UFFD_CTX); > if (merge) { > - fput(file); > + /* ->mmap() can change vma->vm_file and= fput the original file. So > + * fput the vma->vm_file here or we wou= ld add an extra fput for file > + * and cause general protection fault u= ltimately. > + */ > + fput(vma->vm_file); > vm_area_free(vma); > vma =3D merge; > /* Update vm_flags and possible addr to= pick up the change. We don't >=20 > It's very nice of you if you could help test this patch as I can't repr= oduce it in my product environment. And many thanks > for a possible Tested-by tag. Take another look at the Cc list and the link below. https://lore.kernel.org/lkml/20200911120222.GT87483@ziepe.ca/