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 BDEA1C3DA63 for ; Thu, 18 Jul 2024 16:44:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FFA46B008C; Thu, 18 Jul 2024 12:44:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 488A06B0093; Thu, 18 Jul 2024 12:44:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DAC36B0096; Thu, 18 Jul 2024 12:44:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0D07A6B008C for ; Thu, 18 Jul 2024 12:44:36 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7E4691C0309 for ; Thu, 18 Jul 2024 16:44:35 +0000 (UTC) X-FDA: 82353446910.15.C4EBD62 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 72E8E1C001F for ; Thu, 18 Jul 2024 16:44:32 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=cDr1KHmX; spf=pass (imf18.hostedemail.com: domain of "SRS0=lxjs=OS=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=lxjs=OS=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721321052; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2Cz/I5l8dDHXgtyrw2M5Qcxf5ieqvbkUTEBQmBY3X8Y=; b=gHCSXCwXdGjrZ4+dFykwYAhCiJZzWtu9GmmtpKrkqHfPoS49QEnPHy4LZ3ntunvMUCG2WB fRgnxSw8KoYnxw721Z7jOJROWGqyeKJT/s1rpKmQUsZ7u37293aiLbcpuvjNtzFrH3Ug2L HioX3FGBScVQ6v+HGU4E5ArV+/dd8h8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=cDr1KHmX; spf=pass (imf18.hostedemail.com: domain of "SRS0=lxjs=OS=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=lxjs=OS=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721321052; a=rsa-sha256; cv=none; b=Zqh0+bqSEJhvYKTwFu0MCpoozvCmQ0o94p8saq617WGRYztliNbXvUkQ9DQ814cFO0eYBn fi+rdY3/J36ZHr2b9MVDZcSPYZRolCW52eg40PUU+pNZFw1J1ubo8guqjcdmkM5+5nWdPv FiwnP5XGIviB28FcekYjk6PHRj2R+3c= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2C30161A87 for ; Thu, 18 Jul 2024 16:44:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A273C116B1 for ; Thu, 18 Jul 2024 16:44:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1721321069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2Cz/I5l8dDHXgtyrw2M5Qcxf5ieqvbkUTEBQmBY3X8Y=; b=cDr1KHmX57wPBWYPVNH/WI1aufn7GU+cXhBjuEMCNhKZYnsA4lJm80LIXHw8Ldov3mENuc tL/r0zTWTMbTp53Q/6nE5caIn7dqsS1X0FyVtwaCnDllxNq9CD10Rf7lv6qsKwkSD6IqCZ DZ0HpVydWpx1BPomwCh8Ld3fikLGzQM= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id f060953b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Thu, 18 Jul 2024 16:44:28 +0000 (UTC) Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-70365f905b6so611425a34.0 for ; Thu, 18 Jul 2024 09:44:28 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUai7qUCbLEWhfwNnHHLIzSmg0K9gKcxfq9MnPQm+T7H+dIcezq+FD965aVRg1XdLDax/GEDM9DUFZ3sXlmDitZkc8= X-Gm-Message-State: AOJu0Yw1Bg0pnQrHjG0Rwi1lAYormECdFZ456G8zvQulJ052pjXkviCI LUlFLR2mZpUPP3a9La4IKdgCOIUKMTYhs/8gepQZeaWZbCJEgUPeaJgl4HBTe9rxpQy97b4xbwS XD4E3bV+Xu/YnqMpFaCghgj6NAx8= X-Google-Smtp-Source: AGHT+IFg2hihQA5p/zfT3BuCQmxcPQIolrcrVrPEEBfqg0oD2VoGvV8EmKoLjLiMH7BaYF+CYsb+tPAyqdXHQ37MeyA= X-Received: by 2002:a05:6870:b9c3:b0:260:fcca:cf90 with SMTP id 586e51a60fabf-260fccad748mr1336306fac.2.1721321067207; Thu, 18 Jul 2024 09:44:27 -0700 (PDT) MIME-Version: 1.0 References: <00000000000037cdb0061d5924b3@google.com> <46f44064-255b-4a1e-9317-f4b168706d65@kernel.org> In-Reply-To: From: "Jason A. Donenfeld" Date: Thu, 18 Jul 2024 18:44:15 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [syzbot] [crypto?] KASAN: slab-use-after-free Read in handle_mm_fault To: Suren Baghdasaryan Cc: "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , syzbot , akpm@linux-foundation.org, davem@davemloft.net, herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, Lorenzo Stoakes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 72E8E1C001F X-Stat-Signature: bdmp6tmot6ik6w9yujgejnu41gbi1cqm X-HE-Tag: 1721321072-232438 X-HE-Meta: U2FsdGVkX1/RegSPHgB9TcQ+2hKcSo8cP6BnfsrTAiB9kOIbUm2mUpOcNAMi1lq1hOUgTHcTMWwnfMFwN7LL3rPGkX2knAqys/Z9HMRmXnLrU57L6FtNU0EndJS+yIcNfFVvEbQ7uQRMWDZ8t3XqgIaLOn5fJMb8sGGoEBHpcytWlWVEXBsTivvP3cMJiHApcBwlFZtOSvhy7dWxE1QnkwOt6Y370PROXch4KxWuTQ2Ci31v0HIQHVI9F9ID0gQUsFw4JM70YrUlA8MS+4RImjUx3LY4G2qAQT4nIX6E453O4H7ETO0Exr2cTMLxb2vr0k3RpdJFuGP2WRHfQOSFmI7QZWTaAFfnbGj7h00fZDs3D/9QWPk36NR+GUgQb+bYI5RAZ7rCQ5TFrqe5jKtfz49GwD4n6WOeFqP+65nTzRiYXEBtFKlKZZrZC6DguhgqkvTuHMKs5nFLklnHTmZFAtHW8niZUZKQMZSISZd+6OLXOGHP9SsfYL9Us3g1+pwuNIo5UvzyHrG9a/Zefr+W+Y8h59+a9jRUfikxcOqJUtl5hysPlXR1RfKhgWlmb3a4hPPj7YO/YWDdEhNBDX5YHB0vmfu0EqO1X1E6uTdwGsUoTDld3tulBvlV/xraQ/EhBjMeSJBsPUJY05ur4Xech00qVIL3pnRGHCZLxxGPTQruUb6cxo8Lpj9lb+atHgv2uxtVBjR7m3ojdLzgX2kwTWag8lCs5Xm5G/YubSwygo4JEvasuudg6EAjrSaFpEE+cnTmKg7vzAD/lgkHU4nO5qwWHw3DjMAZM9LtWBTYJIRYgBDtuIzxFeFA2Coke1t9TvPGgCPZvlCVMGMNVYlDn/mUmrg1/Twy6dxycyWYu3GHSrECoZbkw8pczXVyxCr9hxBPhbpRaRdGPX70hF8Ga2eK65ZZKQdyd6hFrYW+E/rSskpfuEG6BRdA+Um7wV8YAhrYMAAsnFGlP6svcaz fm4/eHhd am5MNVKJ/tCm1Kxcfh1hBX7cyGt0G7S17Yc73rAeuzo4n0oKiRURUA4k3LJ6u9KWjIZ1C+MWbQAFuj9N9L0M+Xm58YCvb8atvT4bzZUbcXjSmchuJqrOX4R/4Ueqs42OdSzzr1KEjEOiP50Dsf7CksUUUqF6MVv3VOeQGdmM7iOM7ywgaEYCQuZa0xmod6tfZetcYgo5/5vkEj9mjuTbnPNdPPTN95K8ty2Yfj9H0HDS3/N45C9oG4scKdahiaC4bmfySqyfZkTr9FP/kyh9fCt1FOz6B74pxyzS0TSJUXj6DEM95Bs1lYyt3OrhK+7RA9Kzb1LaWOc5vs4iVqiDCgEDLNi3NkeTOXepFxn+gwGAbV+Pk5YgPI3rSTyMFjxP0UI/ipXx7ikVm4ET5dP5W3MriAXk7ILIeBn0MC9cJyS34u4LxQABOhcGpWLfzIbHCorg5rT94boXORcjOBRzQ89n9UWG3W+An1HhBE/oCklOMHaw8guHukQbv2h+ceXP5NDGr8k/fbk8OExnT1WmkhgjPjOl+iBhfjorguilZ5SJELYQvUR1CjOUCCMB3leSodRaQFC1aKNB46bb1HSh355fM3K/aiVftwGbUiybSO0NEOlLEBo968bxL3bd649NZLG3Ob/XMo7+ugOJGiJwMV3vpjUrbNw3lPsZTTy9tvG46ZUgT5KpFvDS8PtQnN3kc4ifjk4QRe3rm3zQujj7vOcYNvpGhaT/mncHPY9otBsvJ22QKxkdkcofEISNhvYT7Z5j0FW7nW2+6zT3Q/rFjUXQdjWNsO0W9jpHvu+//YcnezXmWONDZlPN7omzr3yzB3Nuhx1DlZDMD4pB/AM2lIyg9PbTh1XoxV3sc/AzHTlnZB/4C25GEvvyoovUx9AkYfdHZq4p0DsX4a03TD4gwCCseZXj/sHN3KPobPcMpOBQ3848zcQRYzhEHqPCoQv1hzCWtuDwpSgF+Tnbi7ib1slcIQ7Qg 637wZAWo U1s7+fXO7J+/Jl7DWBj4KbMtfqXlyVRoA9CSStkBuboEzNm8lC8BbnB1m6Po3BfpekiI0mkPbu0PJoDZoUY4XbaGNPgKEO8prbkm3NK9ofXGEsceRsilMHYJzQpuQ8nrXktGn3f9hi7MzcbNlsJRXF3yGtD/JSxNxZ4XSrRUcK8Er/PPPoStigwIsSZe/+ZgCQeLr8RXbzFusGbo+KAw0VMAunubsP2dS2puY/mH+v3+L1abgmsf5g== 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: List-Subscribe: List-Unsubscribe: On Thu, Jul 18, 2024 at 6:42=E2=80=AFPM Suren Baghdasaryan wrote: > > On Thu, Jul 18, 2024 at 4:36=E2=80=AFPM Jason A. Donenfeld wrote: > > > > On Thu, Jul 18, 2024 at 04:23:47PM +0000, Suren Baghdasaryan wrote: > > > On Thu, Jul 18, 2024 at 4:20=E2=80=AFPM Suren Baghdasaryan wrote: > > > > > > > > On Thu, Jul 18, 2024 at 3:43=E2=80=AFPM Liam R. Howlett wrote: > > > > > > > > > > * Vlastimil Babka (SUSE) [240718 07:00]: > > > > > > On 7/16/24 10:29 AM, syzbot wrote: > > > > > > > Hello, > > > > > > > > > > > > dunno about the [crypto?] parts, sounds rather something for Su= ren or Liam > > > > > > or maybe it's due to some changes to gup? > > > > > > > > > > Yes, that crypto part is very odd. > > > > > > > > > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > > > > > HEAD commit: 3fe121b62282 Add linux-next specific files fo= r 20240712 > > > > > > > git tree: linux-next > > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D1= 097ebed980000 > > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D9= 8dd8c4bab5cdce > > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D4c8= 82a4a0697c4a25364 > > > > > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binu= tils for Debian) 2.40 > > > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x= =3D11d611a5980000 > > > > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D1= 3ce3259980000 > > > > > > > > > > > > > > Downloadable assets: > > > > > > > disk image: https://storage.googleapis.com/syzbot-assets/8c6f= bf69718d/disk-3fe121b6.raw.xz > > > > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/39fc7e4= 3dfc1/vmlinux-3fe121b6.xz > > > > > > > kernel image: https://storage.googleapis.com/syzbot-assets/0a= 78e70e4b4e/bzImage-3fe121b6.xz > > > > > > > mounted in repro: https://storage.googleapis.com/syzbot-asset= s/66cfe5a679f2/mount_0.gz > > > > > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag= to the commit: > > > > > > > Reported-by: syzbot+4c882a4a0697c4a25364@syzkaller.appspotmai= l.com > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > BUG: KASAN: slab-use-after-free in handle_mm_fault+0x14f0/0x1= 9a0 mm/memory.c:5842 > > > > > > > Read of size 8 at addr ffff88802c4719d0 by task syz-executor1= 25/5235 > > > > > > > > > > > > > > CPU: 1 UID: 0 PID: 5235 Comm: syz-executor125 Not tainted 6.1= 0.0-rc7-next-20240712-syzkaller #0 > > > > > > > Hardware name: Google Google Compute Engine/Google Compute En= gine, BIOS Google 06/07/2024 > > > > > > > Call Trace: > > > > > > > > > > > > > > __dump_stack lib/dump_stack.c:94 [inline] > > > > > > > dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 > > > > > > > print_address_description mm/kasan/report.c:377 [inline] > > > > > > > print_report+0x169/0x550 mm/kasan/report.c:488 > > > > > > > kasan_report+0x143/0x180 mm/kasan/report.c:601 > > > > > > > handle_mm_fault+0x14f0/0x19a0 mm/memory.c:5842 > > > > > > > > > > /* > > > > > * By the time we get here, we already hold the mm semaphore > > > > > * > > > > > * The mmap_lock may have been released depending on flags and ou= r > > > > > * return value. See filemap_fault() and __folio_lock_or_retry()= . > > > > > */ > > > > > > > > > > Somehow we are here without an RCU or mmap_lock held? > > > > > > > > I'm guessing we did enter handle_mm_fault() with mmap_lock held but > > > > __handle_mm_fault() dropped it before returning, see the comment fo= r > > > > __handle_mm_fault(): > > > > > > > > /* > > > > * On entry, we hold either the VMA lock or the mmap_lock > > > > * (FAULT_FLAG_VMA_LOCK tells you which). If VM_FAULT_RETRY is set= in > > > > * the result, the mmap_lock is not held on exit. See filemap_faul= t() > > > > * and __folio_lock_or_retry(). > > > > */ > > > > > > > > So after that there is nothing that guarantees VMA is not destroyed > > > > from under us and if (vma->vm_flags & VM_DROPPABLE) check is unsafe= . > > > > Hillf's suggestion should fix this issue but we need to figure out = how > > > > to make this path more robust. Currently it's very easy to make a > > > > similar mistake. Maybe a WARNING comment after __handle_mm_fault() > > > > that VMA might be unstable after that function and should not be us= ed? > > > > > > CC'ing Jason. > > > > Thanks for bringing this to my attention. I'll incorporate Hillf's patc= h > > and also add a comment as you suggested. Something like the below? > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 18fe893ce96d..f596a8d508ef 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5660,6 +5660,7 @@ vm_fault_t handle_mm_fault(struct vm_area_struct = *vma, unsigned long address, > > /* If the fault handler drops the mmap_lock, vma may be freed *= / > > struct mm_struct *mm =3D vma->vm_mm; > > vm_fault_t ret; > > + bool is_droppable; > > > > __set_current_state(TASK_RUNNING); > > > > @@ -5674,6 +5675,8 @@ vm_fault_t handle_mm_fault(struct vm_area_struct = *vma, unsigned long address, > > goto out; > > } > > > > + is_droppable =3D !!(vma->vm_flags & VM_DROPPABLE); > > + > > /* > > * Enable the memcg OOM handling for faults triggered in user > > * space. Kernel faults are handled more gracefully. > > @@ -5688,10 +5691,15 @@ vm_fault_t handle_mm_fault(struct vm_area_struc= t *vma, unsigned long address, > > else > > ret =3D __handle_mm_fault(vma, address, flags); > > > > + /* > > + * It is no longer safe to dereference vma-> after this point, = as > > + * __handle_mm_fault may have already destroyed it. > > __handle_mm_fault does not really destroy the vma. It might drop > mmap_lock and another task might destroy it from under us. Err, right. Okay, wording time: > Warning: It is no longer safe to dereference vma-> after this point, beca= use mmap_lock is dropped, so vma might be destroyed from underneath us. How about that?