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 5ACEDC3DA63 for ; Thu, 18 Jul 2024 16:20:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5AA46B0093; Thu, 18 Jul 2024 12:20:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0BDF6B0095; Thu, 18 Jul 2024 12:20:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D3016B0096; Thu, 18 Jul 2024 12:20:36 -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 7B91F6B0093 for ; Thu, 18 Jul 2024 12:20:36 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2264680EFD for ; Thu, 18 Jul 2024 16:20:36 +0000 (UTC) X-FDA: 82353386472.14.D27DE27 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf23.hostedemail.com (Postfix) with ESMTP id 5831C14001B for ; Thu, 18 Jul 2024 16:20:34 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qCIvaICO; spf=pass (imf23.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=1721319602; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=lILN5rf74EY22tXQqLlsA80shtW/3IjUrkRneIFJQHQ=; b=QCs3Sl4iByDIg7RrEQY2FEvZWDVQQ9w5KkJmvoftuNh37HbyOcsGWWn46rzS/+xVKzIFc6 2aHCqjQwjuSDgO4MAl6TKkwnT2Lv9A6cLssT4hMdAg21Jm5wFpkBofB4GMo/GebJrdCmlW BB7/ehkeEXB+ou/YKM4fsu4jBdlNIyw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qCIvaICO; spf=pass (imf23.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=1721319602; a=rsa-sha256; cv=none; b=TXbuOpbegbS3AiKmxNlVcDSPnhowRoSDwEL407My6mZ8SJluybwNzZqAxaydx4ReOAIXRU 95ouVv31NCbXXeMKkTMh5ZDMe8Rr2BwDOgdOKLueQ/MwgqH3BvYM1cNFNYeNUZqCJE8Hex NbUYKr5OKG1h6nJAwZGBFGJVPxlWuXc= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-e05e94a979eso870670276.0 for ; Thu, 18 Jul 2024 09:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721319633; x=1721924433; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lILN5rf74EY22tXQqLlsA80shtW/3IjUrkRneIFJQHQ=; b=qCIvaICOVhV9xsINy266nKuB82sqWXwWNsC7C8LtfH+XVZA2smcb77maf4DQ0+8i0A eiLCXJjuGMVQ+Jk3WdAJdx/VMtTpez6MhzJ+U7p9wJxYvCnuLDLwRzkOllMO9HdnePLt aV8g3yiv+FhrigLczPaeYolsslcc8MfEuNfVQ0hJaA5H14QcUXaW3U/flO5GedUAe70j LlgTmmc7VC0ot3KKcvtKxTxHALuYPV6zoU7Ba+8sKN0oxcG73uP7aXDVZS103jRbeWts IA56hMlkGlMucPDohCG9Z6hfSqtPzv005TH9j4S42F5TCIGdrxHwDXNgqVPFwZO7zU8+ JUHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721319633; x=1721924433; h=content-transfer-encoding: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=lILN5rf74EY22tXQqLlsA80shtW/3IjUrkRneIFJQHQ=; b=UfyPZBgjE4RM8vn+WB36T1MfleObmALUpjnNjk2ARpTnCIa1zCmyyn/7ZkIx1ckMm/ QUZb3xkhgVAQYde6/5GEi7Wj8m01MTCYTqa2xZefa4oWtQigh23Zh8jg+45Xd43aHQ3S vUJiWtNkHLsg60LOh5pBIcHYnSHvLac79dJWo1vIf3sPjfDuRjYHf1jlbmCXwMU5I4bP KINnE+PGVdIYmw6WhP/u4mSY/bH6ficiQCWxN0K5u0MhejlPJynNHItlxd3WGIwDoa3h V2mYv0iCVkbRLETbezCU8PX4EUDGJaTJcqrcT3eFvHzQw2qERJe/L1kdR367++RtPt86 XqkA== X-Forwarded-Encrypted: i=1; AJvYcCWilOC2bSts1dlboMOURZYeY7fg6/jeC9gG/rhDpj3ivCbvF1Id/poq2HPA5O32meh4N95BNPCh2KufrHHn8Ot18Fw= X-Gm-Message-State: AOJu0Yw+hLXFvVyEzVqPQaDhPMG+sTi5CGfkBmeA/VIomUXTeykxEgas xHNBhGl4sH8pszvrfzzpvQxw2IeVK4TH5l4OmOfnyfpzkj7Ks8lo3C1vZlYtZaTS59cppFu6pwf VWrnzH1qoRv1B6UY/zYDrFvF3MDMdkZzfbdTL X-Google-Smtp-Source: AGHT+IG1XNLMtQBmGGne/pYbSYHfyNzb3xFbD8Ml/G5pMbaMDV3lm+sV9cS8QLiXNUyQc8Ei64Vg66xPh8v0AAqJWhc= X-Received: by 2002:a25:26d0:0:b0:e03:a1fc:d086 with SMTP id 3f1490d57ef6-e05ff1a7010mr2575666276.3.1721319632840; Thu, 18 Jul 2024 09:20: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 16:20:17 +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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: t13hq5ymqx4knmwznsai4ib1s74b1f5h X-Rspam-User: X-Rspamd-Queue-Id: 5831C14001B X-Rspamd-Server: rspam02 X-HE-Tag: 1721319634-614654 X-HE-Meta: U2FsdGVkX1+ypO5Qx+mB5uqquJYqNJIS4nuxo7VXKeLjgR2sEVV0ybNG/oN0v1tME8ewyCnTgo8AM+jHuM+NvXX5/VDQM6Aa/6/oqEsJriDmxK/MTjaouoi3jnbT+V/lutvh962Kitp/sqE4bjp6B1nqqCQwhgveySIIAbjrk28pG2+Z9xT84WHJfdWcDKpMIDJvxC5ebo0Vj4FKtSkNnGEkQ+1N34Iy2vuHMMr/4Z9kTFp71C/pXOvtpQQg39hrVHqjtuvgLnJDp5dQwEYlAvtMkQCaolUms2n+AceGjDPSmsFVUFwp0lAlU0H8nx8PIHRUfKsWNlzMI/gtaMBV2bhnviuJO90YRoJpvhP1UhWO9wSWv8AKO9ZbIsEuvNxniFkaQH3ThFpHzKNHDEDaAv+3/WtA6Gto0+tXzFtuR7w73QitiLKkeN68dNPzGW7HtUFokSAQVRCG6rXzM3KPQpDhTYE98aXJdISfU4eqREOmjlaI/IXeuth8oxHqtSylc4S0sGlfgCS54cpiZQLYONORa+i10akc9YIvfmTgTQre1WX5tTbOVpYylaIiYLQ27leTox1jHmyIwiu01ko8cjqKBwAVxsEEKXgb85egD8WbvlC3OBfBJ/LGSLXGHv46sRJstA0pb3tn7Ar/kKuIiczlgNECKefumZWs1jKxhXMZ+SV8O62vENbII2/sEw8A+F6j1PFi8oEDSvGR1bcpwDWfYkbNVhQLM2llzbtFKqyiltNY+y8giOAt0jNButQFAFTSZt2Mve5UM1jHXJTKc4k+IYdRbR+DFlEitFe6bLZ04EMhnHFuqaO+3kOopEFKyz0h0c7Cq6wxwDkt+5llJkTwMDvul7IdpC2W663OE4i3Y1yvsQk5JF6f4ZemDpfzKcokgPPHPm21d6bQbtHpM5W0N697vMQdXmSXYcCAieGkxK2QPdW/y3Vp0o+YJinFmSsXXhKQqM7MfcXUsJF mKkcoGsf G8nckNuBLNuyz2Dq6JEADxbjf36XSQC188UubW3ZN3+ME5FN4xFtwCRZlFozz0wdSUv5KEST3gcAMGqea3FssT6+FLA+z/1m1uLOrlWeRdurBteOnZQ/8zu1plp2cio8PrgPM8jXw3wv+R57BJZJaW9h6tN58WH4UcZ/U4iat2IXMibUaS9L+TY0YiE4hjIr/N0bJ6/oP/Un2UxguiUtadCcN5iPBd7reXD2uxnZoYciBT3UkseJjTX9Wc/iuWZFXF8NmX1s7g7wgEuW5xWc2wsGBjalwka61zIEr8DGRq9pGLc0/QBLXCQECEM3HIzwIRMX0wla51Ofz+MeusYIhqpVpf21/Ul//6Mvd+CbEIzZzcPgWi7JkcjXCPP8zFYk/5UL/tUBLO6fmvkrPDt0cizZmaFWPy0K/2kBLTmefTVMgE92C+PJHvQLVFvFQGsz6+uPWycSUw/w2z9ajZdo8V9AtdlR29/6Mz1Gwm1xsFgLiMO3F9jgT2SO13VFY5F1fd8i+svVPFD9KIOPgie1kEUhifhw2Q5P1xFRE9WVEu07+3MJ099W+226y4rnCG+WkIEWCbYlb8f1K6/0tnu9DklESdek2bKL5sRsdE4j1KuC6/0okAkwfuBbjS0oYgZnKlO6ZIpFA7wb7odb6tZRSKe5vjmg6WaOkvgvHwSiMdNo3fP//gfL/czkPBaBsJDO5hBUHDenSNAm22cKxHNNO5/4SShXJAWjAviLhrfX5YbRL6OzyNZkXTuUhiqYsINe7Ndo8lAQcmKu1lbHc2vYctXDhyl8udPDdPGLpzYfcbBy/+p0Nd7Pqb2BPNjv4jKI2K4B6Tfincd9Sq1wXinZa8NpXzQIJfYAm1yNlNpd83jLrXYiyn1/nHt0vuw== 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 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 L= iam > > 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 202407= 12 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D1097ebed9= 80000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D98dd8c4ba= b5cdce > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D4c882a4a069= 7c4a25364 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for= Debian) 2.40 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=3D11d611a= 5980000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D13ce32599= 80000 > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/8c6fbf69718d= /disk-3fe121b6.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/39fc7e43dfc1/vm= linux-3fe121b6.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/0a78e70e4b= 4e/bzImage-3fe121b6.xz > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/66cfe5= a679f2/mount_0.gz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the = 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/m= emory.c:5842 > > > Read of size 8 at addr ffff88802c4719d0 by task syz-executor125/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, BI= OS 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? > > > > faultin_page mm/gup.c:1194 [inline] > > /* > * mmap_lock must be held on entry. If @flags has FOLL_UNLOCKABLE but no= t > * FOLL_NOWAIT, the mmap_lock may be released. If it is, *@locked will b= e 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 address = space. > * > * This is used to implement mlock() and the MAP_POPULATE / MAP_LOCKED mm= ap > * 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 it > 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 48 = 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f= 0 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: 000000000000000= 9 > > > 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:10= 43 > > > asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idten= try.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 > > ... >