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 51E55C77B7C for ; Wed, 10 May 2023 16:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF7046B0072; Wed, 10 May 2023 12:10:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA7136B0074; Wed, 10 May 2023 12:10:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6FD46B0075; Wed, 10 May 2023 12:10:08 -0400 (EDT) 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 A96D46B0072 for ; Wed, 10 May 2023 12:10:08 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4F3E1AD2FC for ; Wed, 10 May 2023 16:10:08 +0000 (UTC) X-FDA: 80774832096.28.8887EBE Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf27.hostedemail.com (Postfix) with ESMTP id 76FE440039 for ; Wed, 10 May 2023 16:04:47 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=e4cjbj0D; spf=pass (imf27.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683734687; a=rsa-sha256; cv=none; b=b+Y7o34UKN8JWTBFucJzCMhueNjFqfhrO9GmmZRGYjaLfuPYVvEfT0IOt5WK9W/UKEe/Mg AAgZv2GY7X6Fr+n9GxBxoH47Cruk4cIg1A1KH/2oYg3zxk28uq7Mamcl8rcKfz+RWfbiDD PtNEXf6dxINvAeNwTFIYrh9yy1D0Pdc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=e4cjbj0D; spf=pass (imf27.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683734687; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+ajUQgUBCsxO/g/v/AWQSVDSd3dNz3bOeWXMda16LSM=; b=ME2I1xRV32zWkUhXnObR9l7Ga/zcRYOv9WmIsOs/ggsQD7Rsb830xDQ9RzCIjgsdGsQvi1 BXN2X+QOqj5cUVKt1IwlH2Xu3dZnwDurS9gjytK0AnfCZ6YRXknIPvcNnmQC6HMGliOPrr oyp8S9AFNCL8nK5maarVKPxnn5ZsaAQ= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1aaec9ad820so69682195ad.0 for ; Wed, 10 May 2023 09:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683734686; x=1686326686; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+ajUQgUBCsxO/g/v/AWQSVDSd3dNz3bOeWXMda16LSM=; b=e4cjbj0DoYu4kMLUircZ3XabDr0O3k/YGt0ICNVUdyf/cjuXO4sOojjoDCtT1FtM1H VdIl1a/yqeSJ8v6Cdko5G+Kw+dmpj8xDbv20JzV46dM8ES59Qth1sr/pRs+V5bCx59zJ DE+3h57agVfYtgZn1Z8YpgLeUbpQPeiRddBdyeg58aiK64P7ZCZBRp4p2+mpm3Cck8ai abylkmPXpx8sMTIs/7GJYGGaBi+B6fV6MRFScD6UJG5GgAf7H1vu35mtQX3CoYxVG+Ce tppOudG3euVE3othmaXT06sUSrBT6JFN/YN2oVblBb3bI3P5t0Qj4vVJ0oOHKTyyYVdM o1GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683734686; x=1686326686; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+ajUQgUBCsxO/g/v/AWQSVDSd3dNz3bOeWXMda16LSM=; b=OVXT3XvibpOZsdjlMBXXwv+SFUGjtKtF42zR4hy9YkDUyW8JVXJqIqBvJ7t5h4JPGF mksSQkfngi6NWbCS+BYuOJ/VJ+LhF+3syc4PpFrzS1nNu3VEs9+5ccrABXBTfma4mZ30 VrLoZC47bR7Blnu+RYg0q9JGcQns1tPoBZetGqVtmpXRztoXoqqLt6sgw8TMlzDmgfY9 m/r4bXvrhODYCjGUPA0+hoykY5c8b4x6CFdMTOcVlPXCiY+2rlnV3n7x7eEr0iCHFnq2 zl672xnXz7lXjB7uRIUw9ONBRXSmGjUj9ui2prFLHKtTWHr9jv60YuN4DOAQiE8Ri+5M cbcA== X-Gm-Message-State: AC+VfDwBv+pbz8flH7PltgMx+/2VjREMu8bC6tkpDPN7xyGFo+wyNZfi fJcMCJ+QU0VBbBiQfaJT2jc= X-Google-Smtp-Source: ACHHUZ5Oq2uBY7esd1IoBio2KQKnb+8i85L130ldaLUhPH3rmiU2b7xgoU69yuNjLfdGS/QUFadznw== X-Received: by 2002:a17:903:1249:b0:1a6:81fc:b585 with SMTP id u9-20020a170903124900b001a681fcb585mr23345887plh.41.1683734685643; Wed, 10 May 2023 09:04:45 -0700 (PDT) Received: from localhost ([2001:4958:15a0:30:c4b3:fc4f:6ca4:f972]) by smtp.gmail.com with ESMTPSA id jg22-20020a17090326d600b001a66c4afe0asm3955353plb.255.2023.05.10.09.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 May 2023 09:04:44 -0700 (PDT) Date: Wed, 10 May 2023 09:04:44 -0700 From: Lorenzo Stoakes To: Mark Rutland Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , "Liam R . Howlett" , Vlastimil Babka Subject: Re: [PATCH] mm/mmap/vma_merge: always check invariants Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: o9rh3jxdokf3xw4sd7zjo83fwxnmay6y X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 76FE440039 X-HE-Tag: 1683734687-477885 X-HE-Meta: U2FsdGVkX18gQ2vRBF3VkwLQy54ro3yvSxuFrOCvd4eeAbsUynjXOsK3HNZIhtML9BNUzzQL1XwL1wNl0/18xeOw+bWz/asIygBywRWNmsJF9kLwOVpwKhfXc8+JbJI8LTKp+J28hdk9kvtjzVtGj0IY05ZWMv3IGAJO8JMDYX6rigDT5crTnX83vkkI4VhmbWhR2z+J3DaaeH6+PR69MoUrvuKorgu0u0GwN+0ZHnm6xzkgXM8ZNuWNm5iTuW6ViVnX53mysj0nuomluBt7MRq55wkrgb5EkpH5s3DrWZeSPhYZsIQvxF2ycZCwGTEGbrd5o1txj2k9Zoa1U57bcbI8c7NwE44RW1JmP5jW4jQIyJ3/endGJg8/UuQvJZGGbM1hV3IBwlmAZJKpqQELxrMNIAm9+6v4MIxOMcpqCv4aiHRTrPLZJn81JLupvzs7hYmNdOyoEG6hYzZHSdEtwv5yK0+JgVwi+qIX2f9TUlYDDh1Vg9NO882ljz8Tls48tr2ip4sVWaaAG2tKXuff4Zh1xMfqohZX+Sa9iVei1CQINSH+jxuxZOVejZj/xnEilRj029zatcdwYJmki6pQDYcYUEWDJe6Ryh0AGoryPdvfScBPC6G26yu3bij9FDfOqK5VmNqpo6atWhBglTxZ8pi04zqdz2g5F7TEVb3V0cwA6Kx/cJgy72G7Q46fl8pgFQsqtmBbbfNyK+zCdlMO5Y56R+hY9vqPGJalMUqIDRMfB9WB2uLxLmO0UupYUaY8Ce1XAov63ediUZWBND/WBQwW0hO/qffar5VgBYlas639eEN0TK9gBZ0bAOIXuEPytjSJJ7pCQT4ZwB4VLIUvykoJdV6YmbVrQpi3+USIjNGFg1iW/6BD5+7qhcu2aMHybCIAMv+rfO9rNSY8ywaRhYpfPeDhPVd33cuZ62BbmrdEFg4NKu28lYlCOQwfG2Gtd/D5ftANffdYdpt86qT 2LxDlQEB H0/CLMCZuyITXad/ACXA+Bg+CBfMt6fiA8NR5S5RILLfF1wSlidQiym8TnkQ3DgeRkzNz+KUf9WGJaUChJpq1qLasUs24UA1Rzy50O/pO0TvE1X/pitkGxKVQl+6aOo1AyUPgHPa2GN/35aLLttlYCmy34ZdqlarokbD/sJ4E2WDWuI1V/ri/FujmXtexqmMgPc3Vfo4/WlZr6bi40KoCEL/eS6EFeCZNt2YfDXDJVxoOr39k4LV+Gy5ssZICvkGss+w7+K9GUZSx+EZnlc1SnA2acR3dfvz5XOiWC4h4C5pELY0aqUY+jnJdUm/cmxtnzfA7s7dQViK/8QWY8TC+Evigx62TKFFeu8m3EPyDkUkXc4Rj77W9PMjG9dpopFXgklSJGaF01BCkHjSVDn8XOucK+618c5ngnz9s+dYtQrX1UQ8qhnBGLZUplTRYvizHCNAsEJOXbwthFXmCdjKPNJAf4duECwTLui+4/0Et9M5uI82DPGL0XLvxL0VrRkrD15xgO76S5JA8jHFJjP8oKzI4WQ== 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: On Wed, May 10, 2023 at 03:15:51PM +0100, Mark Rutland wrote: > Hi, > > On Sun, Apr 30, 2023 at 09:19:17PM +0100, Lorenzo Stoakes wrote: > > We may still have inconsistent input parameters even if we choose not to > > merge and the vma_merge() invariant checks are useful for checking this > > with no production runtime cost (these are only relevant when > > CONFIG_DEBUG_VM is specified). > > > > Therefore, perform these checks regardless of whether we merge. > > > > This is relevant, as a recent issue (addressed in commit "mm/mempolicy: > > Correctly update prev when policy is equal on mbind") in the mbind logic > > was only picked up in the 6.2.y stable branch where these assertions are > > performed prior to determining mergeability. > > > > Had this remained the same in mainline this issue may have been picked up > > faster, so moving forward let's always check them. > > > > Signed-off-by: Lorenzo Stoakes > > --- > > mm/mmap.c | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 5522130ae606..13678edaa22c 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -960,17 +960,17 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > > merge_next = true; > > } > > > > + /* Verify some invariant that must be enforced by the caller. */ > > + VM_WARN_ON(prev && addr <= prev->vm_start); > > + VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end)); > > + VM_WARN_ON(addr >= end); > > + > > I'm seeing this fire a lot when fuzzing v6.4-rc1 on arm64 using Syzkaller. > Thanks, from the line I suspect addr != curr->vm_start, but need to look into the repro, at lsf/mm so a bit time lagged :) Am looking into it! > The splat looks like: > > | Syzkaller hit 'WARNING in vma_merge' bug. > | > | ------------[ cut here ]------------ > | WARNING: CPU: 0 PID: 193 at mm/mmap.c:965 vma_merge+0x21c/0x1158 mm/mmap.c:965 > | CPU: 0 PID: 193 Comm: syz-executor105 Not tainted 6.4.0-rc1-00001-g7d54d3135001 #1 > | Hardware name: linux,dummy-virt (DT) > | pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > | pc : vma_merge+0x21c/0x1158 mm/mmap.c:965 > | lr : vma_merge+0x21c/0x1158 mm/mmap.c:965 > | sp : ffff800018ec7970 > | x29: ffff800018ec7970 x28: 0000000020000000 x27: 0000000000000000 > | x26: 0000000000000000 x25: 1ffff000031d8f42 x24: ffff000010d58000 > | x23: 0000000000000000 x22: ffff000017acc9b0 x21: 0000000020ffd000 > | x20: 0000000020ffb000 x19: ffff000017acc8b8 x18: 0000000000000005 > | x17: 0000000000000000 x16: 0000000000000000 x15: 1fffe00002f27494 > | x14: 0000000000000000 x13: 000000009a8feb3a x12: ffff700002ddc77d > | x11: 1ffff00002ddc77c x10: ffff700002ddc77c x9 : dfff800000000000 > | x8 : ffff800016ee3be3 x7 : 0000000000000000 x6 : 0000000000000000 > | x5 : ffff000017939b00 x4 : ffff800010c4a000 x3 : ffff800008000000 > | x2 : 0000000000000000 x1 : ffff000017939b00 x0 : 0000000000000000 > | Call trace: > | vma_merge+0x21c/0x1158 mm/mmap.c:965 > | userfaultfd_register fs/userfaultfd.c:1485 [inline] > | userfaultfd_ioctl+0x378c/0x4240 fs/userfaultfd.c:2050 > | vfs_ioctl fs/ioctl.c:51 [inline] > | __do_sys_ioctl fs/ioctl.c:870 [inline] > | __se_sys_ioctl fs/ioctl.c:856 [inline] > | __arm64_sys_ioctl+0x184/0x218 fs/ioctl.c:856 > | __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] > | invoke_syscall+0x8c/0x2d8 arch/arm64/kernel/syscall.c:52 > | el0_svc_common.constprop.0+0xf4/0x300 arch/arm64/kernel/syscall.c:142 > | do_el0_svc+0x6c/0x180 arch/arm64/kernel/syscall.c:193 > | el0_svc+0x4c/0x110 arch/arm64/kernel/entry-common.c:637 > | el0t_64_sync_handler+0xf4/0x120 arch/arm64/kernel/entry-common.c:655 > | el0t_64_sync+0x190/0x198 arch/arm64/kernel/entry.S:591 > | irq event stamp: 2212 > | hardirqs last enabled at (2211): [] local_daif_restore arch/arm64/include/asm/daifflags.h:75 [inline] > | hardirqs last enabled at (2211): [] el0_svc_common.constprop.0+0xac/0x300 arch/arm64/kernel/syscall.c:107 > | hardirqs last disabled at (2212): [] el1_dbg+0x24/0xa0 arch/arm64/kernel/entry-common.c:405 > | softirqs last enabled at (2190): [] softirq_handle_end kernel/softirq.c:414 [inline] > | softirqs last enabled at (2190): [] __do_softirq+0x8e8/0xe50 kernel/softirq.c:600 > | softirqs last disabled at (2183): [] ____do_softirq+0x1c/0x30 arch/arm64/kernel/irq.c:80 > | ---[ end trace 0000000000000000 ]--- > > I can reproduce that reliably with the below: > > | #include > | #include > | #include > | #include > | #include > | #include > | > | int main(int argc, char *argv[]) > | { > | int uffd; > | void *addr; > | > | struct uffdio_api uffdio_api; > | struct uffdio_register uffdio_register; > | > | uffd = syscall(__NR_userfaultfd, 0x801ul); > | > | uffdio_api.api = UFFD_API; > | uffdio_api.features = 0; > | ioctl(uffd, UFFDIO_API, &uffdio_api); > | > | addr = mmap(NULL, 0x1000000ul, PROT_READ | PROT_WRITE, > | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > | > | uffdio_register.range.start = (unsigned long)addr + 0x10000; > | uffdio_register.range.len = 0x2000; > | uffdio_register.mode = UFFDIO_REGISTER_MODE_MISSING; > | ioctl(uffd, UFFDIO_REGISTER, &uffdio_register); > | > | return 0; > | } > > ... which is cleaned up from the orginial Syzkaller reproducer: > > | Syzkaller reproducer: > | # {Threaded:false Repeat:false RepeatTimes:0 Procs:1 Slowdown:1 Sandbox: SandboxArg:0 Leak:false NetInjection:false NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false NicVF:false USB:false VhciInjection:false Wifi:false IEEE802154:false Sysctl:false UseTmpDir:false HandleSegv:false Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}} > | r0 = userfaultfd(0x801) > | r1 = dup(r0) > | ioctl$UFFDIO_API(r1, 0xc018aa3f, &(0x7f0000000000)) > | ioctl$UFFDIO_REGISTER(r1, 0xc020aa00, &(0x7f00000001c0)={{&(0x7f0000ffb000/0x2000)=nil, 0x2000}, 0x1}) > | > | > | C reproducer: > | // autogenerated by syzkaller (https://github.com/google/syzkaller) > | > | #define _GNU_SOURCE > | > | #include > | #include > | #include > | #include > | #include > | #include > | #include > | #include > | > | #ifndef __NR_dup > | #define __NR_dup 23 > | #endif > | #ifndef __NR_ioctl > | #define __NR_ioctl 29 > | #endif > | #ifndef __NR_mmap > | #define __NR_mmap 222 > | #endif > | #ifndef __NR_userfaultfd > | #define __NR_userfaultfd 282 > | #endif > | > | uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; > | > | int main(void) > | { > | syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); > | syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul); > | syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); > | intptr_t res = 0; > | res = syscall(__NR_userfaultfd, 0x801ul); > | if (res != -1) > | r[0] = res; > | res = syscall(__NR_dup, r[0]); > | if (res != -1) > | r[1] = res; > | *(uint64_t*)0x20000000 = 0xaa; > | *(uint64_t*)0x20000008 = 0; > | *(uint64_t*)0x20000010 = 0; > | syscall(__NR_ioctl, r[1], 0xc018aa3f, 0x20000000ul); > | *(uint64_t*)0x200001c0 = 0x20ffb000; > | *(uint64_t*)0x200001c8 = 0x2000; > | *(uint64_t*)0x200001d0 = 1; > | *(uint64_t*)0x200001d8 = 0; > | syscall(__NR_ioctl, r[1], 0xc020aa00, 0x200001c0ul); > | return 0; > | } > > Thanks, > Mark.