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 57C48C3DA49 for ; Thu, 18 Jul 2024 16:24:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D31826B0096; Thu, 18 Jul 2024 12:24:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE13C6B0098; Thu, 18 Jul 2024 12:24:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA9116B0099; Thu, 18 Jul 2024 12:24:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9DB296B0096 for ; Thu, 18 Jul 2024 12:24:01 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 557BD4067A for ; Thu, 18 Jul 2024 16:24:01 +0000 (UTC) X-FDA: 82353395082.11.240580D Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 8C6E5180003 for ; Thu, 18 Jul 2024 16:23:59 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZTBs05KT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721319793; 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=Sa5uf2OgU+1py4BdDs+igYpgbWk6LV/lNPR8dPB8BHM=; b=w4WoxTqnMLyPHAPoVvVF8HGF6A6JtkAANFmWnOTvBPjxSoQhycPh4tuClgn6BgYseVUSp3 yaj/6vFwTrZZiOVDAlXtEo1mgfIdxm6E1TyOCSRqpofIrxdZ5KwNFeVifxGnUZAb8NMPoZ Otx5H3dshfaFPqQxPN4RfuK4y8X3bww= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721319793; a=rsa-sha256; cv=none; b=2M6f6ZAllnh9ZE9/+Dd4wB1OImOm3RHn6l0Eb9hz7fNizMXUCwLQ3PHQPFFxyXF7hpCkx8 puBbkhiyLanmJZWlCQtHArmRC58wP3tSvkBASY67YpABQFa+/mEFHlujBlxwaH8UoEZdaz ETR7OCU8XfsBt7zwh54zSASfA7vZPAI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZTBs05KT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-651da7c1531so9179617b3.0 for ; Thu, 18 Jul 2024 09:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721319838; x=1721924638; 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=Sa5uf2OgU+1py4BdDs+igYpgbWk6LV/lNPR8dPB8BHM=; b=ZTBs05KT1D+4vqKuJnGOWPUBA1KrUsjVHLaGqiTa20AAIKntO8MR7uS+u4wgNH6cx/ KogKtPQ8K6R9Gk6Ktv4RoBsjOD/ILyab8zgitIUQIQxdGZa8U5CaDP5MlvJX3mQtoAtn /y1pK5qcFDLj0Q0g7jaFBC1ymYI9jZIi4Ool1m4CrFGfpY1dIqWX+eZO6uBENC8moF/J TSKRh3BRV2APH/NVyh3YO5MRKs3x4GlPKkVp+p9/wfoVZMLCvm6BFeeteMQ2tyWDNM1/ G76cLzdPYGVjeeBO7FMnswK6bjLg7ho7gGr5a3QZqxsf6y9FGaNvGog6gayVS3Tk69Ge GZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721319838; x=1721924638; 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=Sa5uf2OgU+1py4BdDs+igYpgbWk6LV/lNPR8dPB8BHM=; b=wj7D2zT0WxB62TxF06UAbXPQ1XyiEcc7y7lqCzVMzr7pir7UBIMufKTe70knR6DnHZ avga3dHa0fp4qmlI8nPaxq3VBturpF+5VbUxeWLAptMm0kToJWqe/ieYYbh09kQVTJEu E63ScQUBRirkpLBUC8CS+/Dvk5RrkZ60T3vGxAFsfezWFgbEe75peOL9YHqzGd5yz4tu U+1EmylELaLb9WiLVV8xx04FQ4ICvKukOyAGti5iTyH569d8IUB/F/tWtaas4Ve/ZiQ7 6IKANkAoNfT6Je/dVxlEPUILxnCsndB2FKjWqLyAe+phv3kZikNlMkT1NN2sNMOpUhqu caww== X-Forwarded-Encrypted: i=1; AJvYcCVngGgZIMgIA6Qq3+JYJa6zWvrF75wHI/TqtMQ8mC0hEfBmOd9nnRUrv2amE8UHe/p+RsVie3CvalRBYenhtuMqGo0= X-Gm-Message-State: AOJu0YyysU/IfmvDvaGbYYGEFhqOtkHvW7M9hkxkTamgrcCeiQ2rhxqw U3TmVWZDlRWicqH+zyHYjBsGX8ou5uJO6DIhKqpbQIG8do/AaO652vuh2DJqTm7GlB3Em6zFmZ/ 8rX+0zHqspEhJc0cVRxp1CGHP9UivaXLc3IF3 X-Google-Smtp-Source: AGHT+IEM9QJw2U4dPnAkXo1B0Gufc3aeplGfPEpz16ljZsZc0hhXboL9lEjgyZGF2ziWEiXapvGKAD9w0hbXg1J8bW0= X-Received: by 2002:a81:de4f:0:b0:65f:e123:b20a with SMTP id 00721157ae682-664fd59ed09mr63762687b3.6.1721319838145; Thu, 18 Jul 2024 09:23:58 -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 16:23:47 +0000 Message-ID: Subject: Re: [syzbot] [crypto?] KASAN: slab-use-after-free Read in handle_mm_fault To: "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, Suren Baghdasaryan , Lorenzo Stoakes Cc: Jason@zx2c4.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8C6E5180003 X-Stat-Signature: x6wex8j7gogkd6s14pwr7pm4mqe53jfm X-Rspam-User: X-HE-Tag: 1721319839-687133 X-HE-Meta: U2FsdGVkX18o3yNfUF91uja62XNVcyrZ5YlVriRRX72r4ghEs+NOwv6eWHnA6HxHvFbwXsBUS8wD3+t2zYHUAO/nhTTeTSEL2au9UKjl+rpb/HZKuhItvERBwdFxeoZvUHoPhE8OLYghaAwyj7hEEfnP5NFZGWKDV5lj9EDzgKnVy0bkbGlCAUXHZEl+6PJ4aGJaZzgTOu9BsimTvCSmFiFt/Wm+EnRnrl6ikk1Rn5QB/o6bOklxREXQIPuqhSqwjazi7g9v4iQz6ON+hlYc1tFOVDXjUfM50LlpgafSokSxadciW+X/m2puqjdYCW98DkuAYp8aiEShi37Ki6s5+Njv1MuWgjFjhP6sMaD3EwEowCEVRq9Aa+LWAPqpcsqYZIknTCJFMCh3yfWYlbTU/VnKRrQt5GzAA0suIOzaerHnNu1AOIrUFQY9WCKORNI7y2Gjv5BSeUL2FjSrjkx1nz+hkm4mdN0ZjEGsTMOdpg6ECFh9WE+c9fdBBVcvsut4EM+3x4ULnAQLd6PK/HfjyAmX705btsSbAtt/YN/WpLNQKryVFQYuwYikTJX8T5HxRo1oz1vfKCtRSpAxcrLL7BsS0ON3ASbR+MxdHFUX0rsF2ZNTlopjxGgh1c8mUfaGg5B98yWTScZjz+uXeMmuOP+zOAuOmO6WRxc/GP599scnjhNWrdui1Z+WtwIoIg7Z8y1tNeNUoh1DdrjSM8h1StoM+JTsIrv/1uavLTK/Qh/nFg62z1pGYpTv05w/K9KovQFN83ZvPOeoW6cTweL2R477WzRPuktI8fLrBnv1q4998PIM2rH/+OzSZMnGLhsZzze/jSaxHr6DjD+MdlNVKM5uKOUx/Mp0H0Y8RrfX/WliJdpVsylk/gea2Py9LkkZj7REMyTfFAOy7JoSMP9Pq7ToJ3HvkzZJLNVx8Zg7GWtZHlsookKhQXOAxKR6G70h0oAguMtI3JT25V+uSxu oyh9b0Sq TEsdy0wzwtaxpsyX0YwbOCna5K0sUwCDr8xuIOCTBHL1oMQqAoDdMM53/SRkUFQupL+xR9GzaGeWqDc4vqvFXJEHFEhfyobOOSsm3+W1K6XrKWg0fuB3yfOhqIqQ0BkA3DwY1MOHwfx8nYdFgypT3UR7s8VW9acChzYhQDLZTz2JiU+5205ppfRxfxYEN9Gnj2pBk+YERg7xqi25s90F5kSYe1GXQR/kIUgLDNmTkQjnpEL6YhxkC8T1UOO0/00OqOwNMkHMCK7OjIFmmy7IpYcfpqmzcU2PZDyqfVEVkQrDWQ7bwn9r7TZQP1N4TLRUtZYcKWJyNP3e7nhpX2f6nVCMWQaK1nUB5eM9DCVSrVgv3IFG1dMu+bKw9qROyuuEloe9ke9tfj/+gIkY1jp5mNhsGDdVcsc/kWL/nrMjMY1y1ZHmFe5W/2yZNZOEWUId0ChThBEWyMzF47gWBHU3BPsXNt9jnGFsCTsW33Y6cyCFlQZ9jq0QRqY0VQPVO0GH96grGlc76sXKqa13J6W4AN2DhTHDN4JakY1DIH3adiqHexYU2VGV32O67ZSZi+uVlAA39/JAsKcmOdtOfvR54z57CB3KxYvDA+wxfjegAPJm8ynMK3fXuK6cL5aSu2KwV2lU2qKX5xAbl4v9tXgAl2bvZrT//wasLCH/ip5m3n2XGqp/ARB2m9N+Yh1G9lqzzjge+AajYpQi1pF3SWFysOLXStYfA5YpuPaKKUvjLGe0/PUQNP52fF5rokutb+wm7HRA4PlrSwkP3PbjdClLhjn+oZbhWJl57RydTVmjLGJJ5kCQ6SUMcGYVAI1j7Vcq50Q0kXWgwK4TM+K34anhHqBjHL4Vz0xf7+0MLgUkgThO5fCzk/q1yzFBFWO+Qge56M8+ePdy6kTOZcBA= 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 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 2024= 0712 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D1097ebe= d980000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D98dd8c4= bab5cdce > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D4c882a4a0= 697c4a25364 > > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils f= or Debian) 2.40 > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=3D11d61= 1a5980000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D13ce325= 9980000 > > > > > > > > Downloadable assets: > > > > disk image: https://storage.googleapis.com/syzbot-assets/8c6fbf6971= 8d/disk-3fe121b6.raw.xz > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/39fc7e43dfc1/= vmlinux-3fe121b6.xz > > > > kernel image: https://storage.googleapis.com/syzbot-assets/0a78e70e= 4b4e/bzImage-3fe121b6.xz > > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/66cf= e5a679f2/mount_0.gz > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to th= e commit: > > > > Reported-by: syzbot+4c882a4a0697c4a25364@syzkaller.appspotmail.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/0x19a0 mm= /memory.c:5842 > > > > Read of size 8 at addr ffff88802c4719d0 by task syz-executor125/523= 5 > > > > > > > > CPU: 1 UID: 0 PID: 5235 Comm: syz-executor125 Not tainted 6.10.0-rc= 7-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 but > __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 set in > * the result, the mmap_lock is not held on exit. See filemap_fault() > * 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 used? CC'ing Jason. > > > > > > > faultin_page mm/gup.c:1194 [inline] > > > > /* > > * mmap_lock must be held on entry. If @flags has FOLL_UNLOCKABLE but = not > > * FOLL_NOWAIT, the mmap_lock may be released. If it is, *@locked will= be set > > * to 0 and -EBUSY returned. > > */ > > > > We should probably have a lockdep check there then? > > > > > > __get_user_pages+0x6ec/0x16a0 mm/gup.c:1493 > > > > populate_vma_page_range+0x264/0x330 mm/gup.c:1932 > > > > __mm_populate+0x27a/0x460 mm/gup.c:2035 > > > > /* > > * __mm_populate - populate and/or mlock pages within a range of addres= s space. > > * > > * This is used to implement mlock() and the MAP_POPULATE / MAP_LOCKED = mmap > > * flags. VMAs must be already marked with the desired vm_flags, and > > * mmap_lock must not be held. > > */ > > > > What ensures the vma doesn't go away then? - I guess nothing, because i= t > > went away. > > > > I don't get it.. __mm_populate() must NOT have the mmap_lock, but > > faultin_page() must hold the mmap_lock... > > > > > > mm_populate include/linux/mm.h:3429 [inline] > > > > vm_mmap_pgoff+0x2c3/0x3d0 mm/util.c:593 > > > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > > > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 > > > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > > > RIP: 0033:0x7f093ce17fe9 > > > > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 1d 00 00 90 48 89 f8 4= 8 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01= f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > > > > RSP: 002b:00007f093cd9e158 EFLAGS: 00000246 ORIG_RAX: 0000000000000= 009 > > > > RAX: ffffffffffffffda RBX: 00007f093ce9f4b8 RCX: 00007f093ce17fe9 > > > > RDX: 0000000000000002 RSI: 0000000000b36000 RDI: 0000000020000000 > > > > RBP: 00007f093ce9f4b0 R08: 00000000ffffffff R09: 0000000000000000 > > > > R10: 0000000000008031 R11: 0000000000000246 R12: 00007f093ce9f4bc > > > > R13: 000000000000006e R14: 00007ffe8008cc30 R15: 00007ffe8008cd18 > > > > > > > > > > > > Allocated by task 5235: > > ... > > > > > > > > > > Freed by task 5237: > > > > kasan_save_stack mm/kasan/common.c:47 [inline] > > > > kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 > > > > kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 > > > > poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 > > > > __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 > > > > kasan_slab_free include/linux/kasan.h:184 [inline] > > > > slab_free_hook mm/slub.c:2252 [inline] > > > > slab_free mm/slub.c:4473 [inline] > > > > kmem_cache_free+0x145/0x350 mm/slub.c:4548 > > > > rcu_do_batch kernel/rcu/tree.c:2569 [inline] > > > > rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2843 > > > > This seems right. RCU freeing of a vma here, so that's okay. > > > > > > handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 > > > > __do_softirq kernel/softirq.c:588 [inline] > > > > invoke_softirq kernel/softirq.c:428 [inline] > > > > __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 > > > > irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 > > > > instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043= [inline] > > > > sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:= 1043 > > > > asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idt= entry.h:702 > > > > > > > > Last potentially related work creation: > > > > Also fine. > > > > > > kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47 > > > > __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541 > > > > __call_rcu_common kernel/rcu/tree.c:3106 [inline] > > > > call_rcu+0x167/0xa70 kernel/rcu/tree.c:3210 > > > > remove_vma mm/mmap.c:189 [inline] > > > > remove_mt mm/mmap.c:2415 [inline] > > > > do_vmi_align_munmap+0x155c/0x18c0 mm/mmap.c:2758 > > > > do_vmi_munmap+0x261/0x2f0 mm/mmap.c:2830 > > > > mmap_region+0x72f/0x2090 mm/mmap.c:2881 > > > > do_mmap+0x8f9/0x1010 mm/mmap.c:1468 > > > > vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588 > > > > ksys_mmap_pgoff+0x544/0x720 mm/mmap.c:1514 > > > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > > > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 > > > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > > > > > > > The buggy address belongs to the object at ffff88802c4719b0 > > > > which belongs to the cache vm_area_struct of size 184 > > > > ... > >