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 84B24C3DA49 for ; Thu, 18 Jul 2024 16:49:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F17356B0089; Thu, 18 Jul 2024 12:49:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC60B6B0092; Thu, 18 Jul 2024 12:49:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB4786B0093; Thu, 18 Jul 2024 12:49:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BC1196B0089 for ; Thu, 18 Jul 2024 12:49:35 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 63D6114011D for ; Thu, 18 Jul 2024 16:49:35 +0000 (UTC) X-FDA: 82353459510.06.D6C009F Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf08.hostedemail.com (Postfix) with ESMTP id 8E8B4160021 for ; Thu, 18 Jul 2024 16:49:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PtQNEMpn; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721321353; 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=ZkZH2FYoDVOzEAvUwq5XuX+scAvrug+/FBbJphKQO3U=; b=kYxysa8XQI4WL/vCTaDZokA+kQXYqR2yEDXZIkVwU8lCWFb7RIqVDit5IGG5xhsoi3cPGo A7VcsKWvvAj5WTLv9x7iNob9FqoecGsW0u34QgqdsMfr8UdSUQDsYXJZCPCpeJuMZ4k5E1 ExNTJCPGRq2KjLvIIrurO0zjhaRcRKo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PtQNEMpn; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721321353; a=rsa-sha256; cv=none; b=jg73wAJQNUXJX8NWYA1rJGaj7ieGGaeMoxEpKj4YdupeMRSAv/L5V68PKACM8Nj33GiSa/ vPu16LhdPKMotRlMV/cWpJ0rkKvVZuOL+0PAt7N4mCXiTNbJLQ5lAK6wTVmKhj6ETGHopR 7V7tmy0juzWwHtNHBQJWDJHbKrm/iBA= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-e036105251eso1118297276.0 for ; Thu, 18 Jul 2024 09:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721321372; x=1721926172; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZkZH2FYoDVOzEAvUwq5XuX+scAvrug+/FBbJphKQO3U=; b=PtQNEMpnLASGVl2WkxJoFYhJANXgVWK2BYivokYcIrjWkyj8I08vTV9UXj4RW99o5K VttceB7yn+6Xmy+KmmhLJS99OjDZJCaKlitY9jaa35SeCMWjSa9p8ZUsZWvJun4cCGlO gSDLfQBu3SLkdxy6T6lKKLNUj+SPy8xR7QfqFbpN/0ZmulvUUW/eK2mnWk9E4b4zy0AW epY7mi52kFKBcLmYlK3QDyrzgzJHfkoHGIwt7YtwoUGU/JcVxIenllOfTGG9agiEODRa pPJ4tdJZ3ek4ee4RNY/Hd60a+It1y5dlpAEgFyHFDxtqSacaulEolOBiBpMf8tRZsrm6 8dWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721321372; x=1721926172; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZkZH2FYoDVOzEAvUwq5XuX+scAvrug+/FBbJphKQO3U=; b=B7JP2H3nGvhxB+WJEpSsFe4i1Y4svQjpjnzrNmwi5wd3Fsgb4sdGILB3CghBuU86p+ GjHAhcbows8jNslPLy9ZMI7SAVTZfWaxTWmR1rq+uv5/VEeEqvrHb32DJiEg1BmECYhl rIGlSuNGRLPM9ekccmI4xSZevM+zxV7fdzE/VO0SuqfDRtXttjIdH/ekrKwKA92DsYoO vn77GR4lrWr3Q5kQvKgDdAds4mcw7KzV4wb9flwZXVCYC4/HewhBsq8GL2p24nk34L0k oY3wZWeZRS8JbItGrOD2pORMXbhqlN1eFUPcfiHIsQJpqXaZ5p1U4kqpSEla/Vp/olIF fxRA== X-Forwarded-Encrypted: i=1; AJvYcCUEm4j9PGyHOjtPxthtSBAIUUvCQLjqSJLbKY/yZT4ZByf++kfZHk9eQGhy90zbDCBRNMUqxpf2BrzUVKWzG2CvBRI= X-Gm-Message-State: AOJu0YywLVvqga8vdjWJr5J4vwiJ+arOw1F6S0CDbeAdTFWWhtZ5T4Nn uUOZlD1Z9BMM7Ce824JSye+UmLrZGMt5+qO7nbk7MQyOBfZzsY90zPLcNEDSD05K+FNPWChQR8a GXfpSxstrcbjn779lsxTDjySGbgn5DKKLJ9jZ X-Google-Smtp-Source: AGHT+IEpvltijk6evqDJoq94UChM5YTgvvy6ILts2O1q38N109QkAR78Yxtbz/O3Co1rYWU4XgsHUftmxubfhsZWJfg= X-Received: by 2002:a05:6902:11c1:b0:e03:9a95:bc78 with SMTP id 3f1490d57ef6-e05ed722c7cmr5882551276.36.1721321372149; Thu, 18 Jul 2024 09:49:32 -0700 (PDT) MIME-Version: 1.0 References: <00000000000037cdb0061d5924b3@google.com> <46f44064-255b-4a1e-9317-f4b168706d65@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 18 Jul 2024 09:49:21 -0700 Message-ID: Subject: Re: [syzbot] [crypto?] KASAN: slab-use-after-free Read in handle_mm_fault To: "Jason A. Donenfeld" 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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8E8B4160021 X-Stat-Signature: uuxpw5hfdxre9mnsh6q3oyecbn7af3u8 X-HE-Tag: 1721321373-887206 X-HE-Meta: U2FsdGVkX1/FP1uXOrb+NxBlBI5CD5MsbekGAtX8d+6m/rEFXH8DjNW8w5N+XeTeNipYnpnOSbJOMINH51kRsE2nyX8jzurqKdkBJ7e+QVPRiorCe2fjcVP0N41K5qlXP7EXbmfadOIfzrrRMUeo2YkCA/Fya5mS5m3Wb3rG07Q4a0WLUr39ss+0oahLcKDFglOeakY4QQkBPk9HMqiE7UaJ9qngagYpHmz8vqMz6sVHBXaOGKyqjkgao39aCjdsc6u0CTIWjyPBgdDu5Bn9MsFjviHVfYRhN3wHs6CnQOOSSRdKDLJrJSSJo+5X6PwPlhgSV5TWM3K5UpbWRyz3LBRszQ2CxLt0XkVKwKYCs56bA+orLaT8XzPkzTyn2dCMjgKDmY35y850oevIOiWvpnFLmG0/eDfYrNLP0tw3rVaWJ5s5yrWM3Csh8EdIY/Haa0t+qcTg2NcXlDhSKgRTublMyeKkMxbC2wHnzR5/mrg8+ukDxqepsZD8gg0nK6JOeo5npUT+UqeqtE7b7o+4f1JyrEZZ3qepbqWerD+WhEWcQEv193JsGkxHKnK1FT6CIT1CAnStSeCGhGS/zeMzGI8v9C9FNqblY83D5zABrrfK96Uz7q5WfMBhr9Hl8A3Sdaa+5XMTCunb9luSwmXp/D40i0uA9dHjHmt+mreByZVAci4ftp63cpRJPt1jbRfdXwr8HHqVqRDhfrNvyPkzzHIfbKd+e19rixEUohDXi9kIqEs30vJ4I8TWwqToY3BP9Y3ikeSFSnQOIvNRawM+9Cj63O6kNjdTs+UgYZBaoJSIT2u4QoeCoPf+smItL9mKntORz1RLWO6s9NTrQq7hXGbv6VUGYPA12iDOCbpK464JgPFj/00l1X+RfZ8A9i6ywks7K7uB60GKkMB96WB4PdKSM10frJr5xw2bOOofgz5lnY/SHy77KPDEiXeF08gYm1qZ0juiu4kaFp3yGJ0 ZZu6cda2 Q1fdAZSXg1z3q+AMz+3M6VEacGm4O11cmcoWwQTHWjZKQ70P7+xM5iXlxMzbvaU2bp5b0QzKRRi/NkvP+tD7t1SXbMW1eiZf5txnEIJT/R0lmLiGEhp/nctCCzw6MsiIA3L/ebw8mpRkCJy6H1nW+S8Wv63xVFBxcVxObPYG3odNS6ZZsx2ZN6eRkxDjakx9VSMzMubrXjcv0MoSQimQCpgl5a4IpWE4d2KbICtlh5N2Cwupc8FuarKrzkjtAdNdrrBZccA+LWN7Lhri01JlnlT5+OyFiCX1DqNRSRarADt/LuUP9d7IcY3ytZ8pvHMnC1v0+G/nLjZc61gTIr2NbQ9VH4wN5m33ZBwBzS4pgmC34+Cpoq8T9drPN7jMDhiDigKWIY3/ki3vpNgVeyocdh5oPnIa0IUpLblu9O3hwsVPv22pakwx1MPSsq2jCX42eUOZO+JcK2ZbL+/qPR/j6I1hgBZB7WyeCJ6g5d8URDwj+2bfFTTUvrmoFb4Id/tq2lD5Bq9F/kppGAH/+pPNr1o4K7Yh3QeqfFOiINrdPIEmLRNMXBTUy03kiz4ADREZom38FHHd9zIg3DgHhxMA5Jx6h+XT1l6PQ1gw7DBjC794fGpiKBE7LfCW4YkCWEh6DQVFt41Vb1bJISs+YP+Npi91Ss2HnVzQMQTU61+b1XXmfM8UH2aM7pU3xv6LAqSMY65wwiBfzR6PNumGV9VNNCkj8DC8n59ahLaIOjOyxmf91XJKtR6h7880A2mXaGluOcvboQNFtdUiiNyTuQi7oH6zcX7sM6DMMs00uHU9rjNO6XIOvDfM6JFfuGvqfPlce3q32AaVR+2RI6j7RdnX2YbBA1IMqiTQwAQMy/1pZFqcumDXO1CVAYbulrTLC/UNsKM0+AHWF0Pcotsm6Nv4gNtskqZX1AcWDfbdOXneuSzJp3seCnuZKTKxtUGf5uKB99XdeXa/oFOVLTjg= 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 9:44=E2=80=AFAM Jason A. Donenfeld wrote: > > 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 = Suren 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 = for 20240712 > > > > > > > > git tree: linux-next > > > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x= =3D1097ebed980000 > > > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x= =3D98dd8c4bab5cdce > > > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D4= c882a4a0697c4a25364 > > > > > > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Bi= nutils 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= =3D13ce3259980000 > > > > > > > > > > > > > > > > Downloadable assets: > > > > > > > > disk image: https://storage.googleapis.com/syzbot-assets/8c= 6fbf69718d/disk-3fe121b6.raw.xz > > > > > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/39fc7= e43dfc1/vmlinux-3fe121b6.xz > > > > > > > > kernel image: https://storage.googleapis.com/syzbot-assets/= 0a78e70e4b4e/bzImage-3fe121b6.xz > > > > > > > > mounted in repro: https://storage.googleapis.com/syzbot-ass= ets/66cfe5a679f2/mount_0.gz > > > > > > > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following t= ag to the commit: > > > > > > > > Reported-by: syzbot+4c882a4a0697c4a25364@syzkaller.appspotm= ail.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/0= x19a0 mm/memory.c:5842 > > > > > > > > Read of size 8 at addr ffff88802c4719d0 by task syz-executo= r125/5235 > > > > > > > > > > > > > > > > CPU: 1 UID: 0 PID: 5235 Comm: syz-executor125 Not tainted 6= .10.0-rc7-next-20240712-syzkaller #0 > > > > > > > > Hardware name: Google Google Compute Engine/Google Compute = Engine, 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 = our > > > > > > * 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 b= ut > > > > > __handle_mm_fault() dropped it before returning, see the comment = for > > > > > __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 s= et in > > > > > * the result, the mmap_lock is not held on exit. See filemap_fa= ult() > > > > > * and __folio_lock_or_retry(). > > > > > */ > > > > > > > > > > So after that there is nothing that guarantees VMA is not destroy= ed > > > > > from under us and if (vma->vm_flags & VM_DROPPABLE) check is unsa= fe. > > > > > Hillf's suggestion should fix this issue but we need to figure ou= t 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 = used? > > > > > > > > CC'ing Jason. > > > > > > Thanks for bringing this to my attention. I'll incorporate Hillf's pa= tch > > > 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_struc= t *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_struc= t *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_str= uct *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, be= cause mmap_lock is dropped, so vma might be destroyed from underneath us. Better but I would change "mmap_lock is dropped" to "mmap_lock might have been dropped by __handle_mm_fault()" because mmap_lock is not always dropped by __handle_mm_fault(). Technicality but better be clear about it. With that changed feel free to add: Reviewed-by: Suren Baghdasaryan > > How about that?