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 B3102E7717D for ; Mon, 9 Dec 2024 13:52:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D2C08D0060; Mon, 9 Dec 2024 08:52:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 382F58D0058; Mon, 9 Dec 2024 08:52:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 224878D0060; Mon, 9 Dec 2024 08:52:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 000ED8D0058 for ; Mon, 9 Dec 2024 08:52:57 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC9B61A058E for ; Mon, 9 Dec 2024 13:52:57 +0000 (UTC) X-FDA: 82875560670.03.F3D76D1 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf07.hostedemail.com (Postfix) with ESMTP id A1F1440003 for ; Mon, 9 Dec 2024 13:52:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x1FHSiE7; spf=pass (imf07.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@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=1733752366; 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=4Z5yTTd8HuCAJ0Vf7H0LL0ubjQfroLQI04Z2LMz1eyg=; b=K5hBQwlzE8GUVX9ixR/sktmrqR3WqH/aNKhgQcDruXeUHjOwuiiIGlJeapMXHc3ZfELtDm uNf6G3izLjNERtrGudgMn8tDcPUzVYTa+11pY+S4BvTTX6GNCRME3cpwjqSq9yzMDul/ob cYHuiVPzf3Zfnfh2LbkL9BmT8KDoiyc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x1FHSiE7; spf=pass (imf07.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733752366; a=rsa-sha256; cv=none; b=KDA7HQJOY//3Gzk1W9IU+KaF3VmVOD4d86PSTqhl4DZSL8SVEG/4j9Ur2oLc796RsorkBM wCjgt8fRuCpXs6iCJlGCrAzXj/kIXs6HODoa2eZ07uP4q61RF2Bz5pAfpgWOIhaFSs9KQN xj+nuozm21XUzJnkSqbSwkvVnwfWa8I= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5d3e638e1b4so8688a12.1 for ; Mon, 09 Dec 2024 05:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733752374; x=1734357174; 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=4Z5yTTd8HuCAJ0Vf7H0LL0ubjQfroLQI04Z2LMz1eyg=; b=x1FHSiE73pvgNRIVaR06wINYt3RcZscw8sN+KeCmI27hqLjpDCIajyEOhvi6b+S/4P V/uZ5OunbFAQEZB33N0relIMf4LOtBLTC6uAdctuXm/PSMwcVgf6Ie3dMRuyoxAPaXT4 /hiN2nQ6N3WNT3Wup96x8gjb4v0UDa50lpLFG6HBg7qDLmw/ZZoHLyBW/MnOOBUgF/1g 2DJdZa4MmtkDQVm+vBLWpsVp02spfGsRHPP2mQt0iH3juTOKBBgSvlkw7sC+Vln+0IRO je7UrxtRvGBcvdsk+WBL/Q4C66TDEBEKAUOcn6AnBtYs/2BFjAZnUdW7hDfEAFy9UcDd 8bNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733752374; x=1734357174; 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=4Z5yTTd8HuCAJ0Vf7H0LL0ubjQfroLQI04Z2LMz1eyg=; b=eolHb9/lv7uYbFtF3SBADU8Eqw5h1mGwvC5Tp3iyZmOBqDOu41s1Y7HC7q6bhCWPsm LliMt9lwBNA8B48+oCdG/OJDEo1bAvGGTpq0w+tn9wJnvVi5AqB62Arj8OkFvrIFSXp5 IoQAG9xM9S08rzD32MeSxxNlm3T7wIX7ueZXFpELi1yy8IXG+8Ro+BBoWNjmWH5n1n4h +cLu6hPjkDx6sH/+ldMzjOd6SGnJIJpduRXg2wEPCn3YOCj59YdzhjZUKs7AhgavFMyz 0tzxOKtvSr4QirIg56CrZJ6TrZGTt+V2SK/o4utwQsi+BdJOt5lpDLtHzu34+9gWRjdW nr4Q== X-Forwarded-Encrypted: i=1; AJvYcCWNjMwgcxxTQYd9vxtgoR2u8hRJSaymLA5MHaCP4zygSyiv2hsgrAsHE2fcGIuE2Yhv1p7aUvTGFA==@kvack.org X-Gm-Message-State: AOJu0YyFPNob4LaOKkHrfsTcLZJUtpnQPLTLbq75pC53SQrJ4VQm9a4+ SrJDS1B3QqbG2du6sHoMy00kgaCiJBtQJqm6M1K5nWIO2sww07hU7t0NUeS4dNLYGV8Vd0ExAfm gxLbr9o0r1p2wA0jVu5tEx5GLYc59ydmhuAv5 X-Gm-Gg: ASbGncvhXdRopRPonSm5kQ+EpjpJm7WL0h1OASuKNCbTXjSYF5+DlM9p8AhQ9OXhAgM /asgQctO4oEgC/J1w+0Xal7ZbIUhaDQrzG070I1sFPE6IlwVBPQ7w8KJFtAQ= X-Google-Smtp-Source: AGHT+IGmufIL/UdCaASQOs4rSgjZXKbwXZiwHoGPg+len/47cPa12dHDcs3iVzxewCu9YCUkwdiWYtnDWgoLQ+0PAwg= X-Received: by 2002:a05:6402:1346:b0:5d0:b20c:205c with SMTP id 4fb4d7f45d1cf-5d3dd9dd1a9mr138376a12.5.1733752373747; Mon, 09 Dec 2024 05:52:53 -0800 (PST) MIME-Version: 1.0 References: <6756d273.050a0220.2477f.003d.GAE@google.com> <1b8b5d54-d667-4ca9-b831-bee4b4e74c40@lucifer.local> In-Reply-To: <1b8b5d54-d667-4ca9-b831-bee4b4e74c40@lucifer.local> From: Jann Horn Date: Mon, 9 Dec 2024 14:52:17 +0100 Message-ID: Subject: Re: [syzbot] [mm?] general protection fault in find_mergeable_anon_vma To: Lorenzo Stoakes Cc: syzbot , Liam.Howlett@oracle.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, vbabka@suse.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A1F1440003 X-Stat-Signature: 9fobq3tmk34xpn3o184jzatuxt7r7kza X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733752354-110046 X-HE-Meta: U2FsdGVkX1/98uLSMAbaylbFs2vP4UiOWhAtAqsL+tfRWOZQQp6B8b4/u1qcNgQqPXuHTOaFTuBBkzFcBxvHm1nnI6ZywRgIdO4wtWDzIUqj++SFQDmB9QmDv4feK3Fs37RFmwkWb/HLhQXSq3RKkpi8g0ugQFgk/5ohI6wMgI0CvBBp56YIiY4hkx3BC7IoyBS5uYUMYicDuoa5Yt8JRDAW/2k1ibC45hZOcoPqb3y44LtU4i9cP5Wqhk1yFjv9Aa++3Ct1BRitIyFlNc4ArisOhcvM79TTS92H7Z+tCLfR2pEY1VJourc+7Oh5HhqRZRWvJKi0OUsQV7+5Apku0v3Hp+q3BonvFzUFEz1yPFFDCVXePbthchdDNFqADzpd0E+cwwNtq413YEThJ5AH3+7iJp2j0EF4YR6sjhI1498NcGaOa0CaT5fWPFnHNYY4Xcz7wiSqD5/2OtqH9JOPfczZ3Ih4mvlSPQgDQRYGqmA/pdEBMBKmFBQdKoE+tQRULJRt7oVAoMaEBzsrY3MiqjgNiOp4o4jIiq/OwsruQQkPAtrBmlhI9kMcisobVPJQv7kSiHvG/HVgPV4bjmvmmT2L6dLohHPk8YhsxLZ/16LiFnjd8TFCr4lg8E9429pRfhId27UJEFhVOeOKMRUpQPPOqfZOun9PkPsKltQ39qA1D2kIrDuPQMgx8gdRCQBFkQm2N/SmVvBKQqffaXE483URjItjnQyjZKJTF3wpk13slMzb1YbIPEBjWQPWwFSg9IiJ6DJXk/jQ+MowAoSExwKgAM64KVa20UpMb911qtlQZK6mKOPinag8dkS5ub9Sp7rEDCy+qIdwwbiVQEMkGBWnvwOw3z8jSyfU1/PqZqUShV1EnIkAT4yN2ZwTgYTLRbf1E0/F1LEA6y3RG8VMOEKgJDW82TA755rdgXMhPgSs6P7mN1rkGq6RWKv/Qm/Osl5CuqtCm7nAD+ltQJx eL9GkA9i RXOH2OPtJx/DCKQCRx72RUDT6w5jNxNyTAST/FFg7CVvhebXRMYps4n7aBLlwEMC8eSx4Tn6W9+rmUqMaZCRz11HhMIvXNpuGD0caoLQNfzjDaUpYnnINiJjUEpbvny3i6gZfwlUh3l29jehml2htS0J3maeZi9Sd+TEhgQOvM473Ab/ZR/fjEmTrbhQPGLyejRs2p1k2mZ42/b+FFkqvEGOGXki6dmkjrQz359eGU6jdsZKwQfoeQ9W1dxMb/MKE4T4R2L8vdlfnA8xM0KJDn9bbqhuFGKyHljuLCAJiDL4jpUhhsLgQydeH4t8oS3SDfi2ewRVOvn2L3RM09UhzEgZIIcdHXrEg29McLhxDOvuOf9Lv3vYSTuOtG710fGiaAQRXYig/01lCQYEW6fp4s2BciUxkMBiL5MqtVVFJ74w7CWCFI6+Ey4dqTkVGDeFx2m+3JP7Jb8j+P0Z+GsHALVpJkJzNsWThQonJSEpvZ2FkZo6LlAWVgDMkEmpPgvyNvtZTLr4ddnAJpekUICubg0W8q+fZZP7g+JZ/MN2SHTFW8XIp7J2OwynlDmumb1VKbZHYvCt7UMAf9ElauPjR6Q4hmltjOt05YuqWIlUHW06LaVqX5yGz+qP+GmfWEeJENT3WxyLgkiCtP6B1St1NMvLw52CLsHrwWBRw2SQPokMt6U3MWSClNDNhhC0gPEJwR6LKj/MafZTzk969x1HvN3pJ/9x9/H0dS5sTVj2ZQOioGFBHX393JonN/CYg9jGG5Pjwt4eQppfqYkrRUv1ytI8mlJHhBtqTpjeUhEnyGe7YjKuGLUjUKcx92XfkpmrqSbtQfZa2ICmaEz/mNHjBiE3yl6M5lgpzhJ/WXSEN4ae8PNrmxL2jFE5Ti8I6qVXra5d0q/8jmr5OBUtw7OGrzmw69i1+HDVl9nb3 X-Bogosity: Ham, tests=bogofilter, spamicity=0.019294, 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 Mon, Dec 9, 2024 at 1:53=E2=80=AFPM Lorenzo Stoakes wrote: > > On Mon, Dec 09, 2024 at 03:20:19AM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: feffde684ac2 Merge tag 'for-6.13-rc1-tag' of git://git.= ker.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D17f85fc0580= 000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D50c7a61469c= e77e7 > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D2d788f4f7cb66= 0dac4b7 > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for D= ebian) 2.40 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > Points to this being racey. > > > > > Downloadable assets: > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets= /7feb34a89c2a/non_bootable_disk-feffde68.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/6135c7297e8e/vmli= nux-feffde68.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/6c154fdcc9cb= /bzImage-feffde68.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the co= mmit: > > Reported-by: syzbot+2d788f4f7cb660dac4b7@syzkaller.appspotmail.com > > > > Oops: general protection fault, probably for non-canonical address 0xdf= fffc0000000080: 0000 [#1] PREEMPT SMP KASAN NOPTI > > KASAN: null-ptr-deref in range [0x0000000000000400-0x0000000000000407] > > This doesn't make a huge amount of sense to me, the VMA is not 0x400 (1,0= 24) > bytes in size... and the actual faulting offset seems to be 0xdffffc00000= 00080 > which is 0x80 off from some KASAN-specified value? > > This would be vma->vm_file. But that also doesn't really make any sense. > > But I wonder... > > I see in the report at [0] that there's a failure injection in vm_area_du= p() on > fork: > > [ 73.842623][ T5318] ? kmem_cache_alloc_noprof+0x48/0x380 > [ 73.844725][ T5318] ? __pfx___might_resched+0x10/0x10 > [ 73.846687][ T5318] should_fail_ex+0x3b0/0x4e0 > [ 73.848496][ T5318] should_failslab+0xac/0x100 > [ 73.850232][ T5318] ? vm_area_dup+0x27/0x290 > [ 73.852017][ T5318] kmem_cache_alloc_noprof+0x70/0x380 > [ 73.854011][ T5318] vm_area_dup+0x27/0x290 > [ 73.855771][ T5318] copy_mm+0xc1d/0x1f90 > > I also see in the fork logic we have the following code on error path: > > mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1); > mas_store(&vmi.mas, XA_ZERO_ENTRY); > > And XA_ZERO_ENTRY is 0x406. > > Now if _somehow_ the VMA was being looked up without XA_ZERO_ENTRY being > properly accounted for, this might explain it, and why all the !vma logic= would > be bypassed. You fixed another issue in this area a month ago, right? (https://project-zero.issues.chromium.org/373391951, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3Df64e67e5d3a45a4a04286c47afade4b518acd47b, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D985da552a98e27096444508ce5d853244019111f) And we came to the conclusion that MMs whose VMAs have not been completely copied and might have XA_ZERO_ENTRY entries left should never become visible to anything other than the MM teardown code? > > RIP: 0010:reusable_anon_vma mm/vma.c:1837 [inline] > > RIP: 0010:find_mergeable_anon_vma+0x1e4/0x8f0 mm/vma.c:1863 > > Code: 00 00 00 00 fc ff df 41 80 3c 06 00 74 08 4c 89 ff e8 10 39 10 00= 4d 8b 37 4d 89 ec 49 c1 ec 03 48 b8 00 00 00 00 00 fc ff df <41> 80 3c 04 = 00 74 08 4c 89 ef e8 ed 38 10 00 49 8b 5d 00 4c 89 f7 > > RSP: 0018:ffffc9000d3df500 EFLAGS: 00010203 > > RAX: dffffc0000000000 RBX: ffffc9000d3df540 RCX: ffff88801cf80000 > > RDX: 0000000000000000 RSI: ffffffff900062a0 RDI: 0000000000000000 > > RBP: ffffc9000d3df610 R08: 0000000000000005 R09: ffffffff8bc6b642 > > R10: 0000000000000003 R11: ffff88801cf80000 R12: 0000000000000080 > > R13: 0000000000000406 R14: 0000000021000000 R15: ffff8880120d4ca0 > > FS: 00007f137f7e86c0(0000) GS:ffff88801fc00000(0000) knlGS:00000000000= 00000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 0000000020000140 CR3: 0000000040256000 CR4: 0000000000352ef0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > > > __anon_vma_prepare+0xd9/0x4a0 mm/rmap.c:199 > > anon_vma_prepare include/linux/rmap.h:164 [inline] > > uprobe_write_opcode+0x1a95/0x2d80 kernel/events/uprobes.c:516 > > Here we find the VMA via: > > old_page =3D get_user_page_vma_remote(mm, vaddr, gup_flags, &vma)= ; > > Actually one unfortunate thing here is... ugh god. > > I think there might be a bug in get_user_page_vma_remote()... > > I will check in more detail but I don't see anything that will prevent th= e > mmap lock from being dropped before we perform the > vma_lookup()... FOLL_UNLOCKABLE will be set due to the &local_lock > shenanigans in get_user_pages_remote(), and if we get a page after a > dropped lock and try to vma_lookup() we could be racing... :/ Hm, aren't we holding an mmap_write_lock() across the whole operation in register_for_each_vma()? I don't think FOLL_UNLOCKABLE will be set, the call from get_user_pages_remote() to is_valid_gup_args() passes the caller's "locked" parameter, not &local_locked.