From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B642B44C50A for ; Mon, 24 Aug 2026 16:14:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787588092; cv=none; b=L3c+uIOhalG4x0qU+LmKXG8CHflcYLDoJib2kcbsSc5cRt7dGk1mLzG3FeyicSXmlHBqyCxAU3m7nwsmvvQ1tvWH5QtLwEZKMl2s0iyLycSKDr2rA3hpr2SQJqtW5VvHFAzSwirz5AAdy//d3q5CTuV7QY1vTf8409o6zJ+M1uU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787588092; c=relaxed/simple; bh=9A4PopJI9CfDa+qGIqXDX5IiJAgsJcfiIXbqJXNeg5M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=i8kofTFoYqieD4hhuYWzfbIauJvcZMeOyW62GY1Y2GzLw705sM+s17c4Srg7bXHLb5+2qI8N4+fKtyfp006kGzH4/JCREN6Y3T9JVXeI8w3+nkOdMP74/sEuHLKNnMY7jbJ6UFMu6pMfaR0QI5QxdbcAWcqe58ocBYtTVWWsOxU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fleR4EN4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fleR4EN4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E1B21F000E9; Mon, 24 Aug 2026 16:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787588086; bh=uCYdRcoHBE/Gq3BI5P9+1NzCBeCMi37CaPje/hdS8Gw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=fleR4EN4mU6mWRvkRfzkfZ9t/Gjht4+f+Yt+bKju+aYXc6UVFPtPpv5H5SERZar3o BAOehAI5Hdr7UX6TkEyAogLM/PdOHAd7UaGpnkmsWpdmlXPLirrVNNlV/jHGW4NJAF qXPJXjd9iDyVeMlhMQmiwfBAydKP2Kgf8hnX1w99G04gk620bjSfUvXi9d+C+SWOsV +QwqpbJ80EImiNfQxrw079GYjHEArcsF/HP3F9bOhhvfSxi0zseCrQzT3GosluivpZ d9YTYtjKF3+AAMcb1r3A5P2YqLkIU3CI2XoGbKm/Jbx0f92oUKU63O2jAr2asYMpKw 1q2eAfbt7iXDQ== Date: Mon, 24 Aug 2026 17:14:42 +0100 From: "Lorenzo Stoakes (ARM)" To: syzbot Cc: akpm@linux-foundation.org, jannh@google.com, liam@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, pfalcato@suse.de, syzkaller-bugs@googlegroups.com, vbabka@kernel.org Subject: Re: [syzbot] [mm?] WARNING in vma_set_pgoff Message-ID: References: <6a87853b.ae6ddae5.3da009.0023.GAE@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a87853b.ae6ddae5.3da009.0023.GAE@google.com> The assert that's firing is the one I added to check that an anon VMA has correct page offset: static inline void assert_sane_pgoff(struct vm_area_struct *vma, pgoff_t pgoff) { ... /* OK this is really an anon VMA - expect virtual page offset. */ VM_WARN_ON_ONCE(pgoff != vma->vm_start >> PAGE_SHIFT); } Called from: static inline void vma_set_pgoff(struct vm_area_struct *vma, pgoff_t pgoff) { vma_assert_can_modify(vma); assert_sane_pgoff(vma, pgoff); vma->vm_pgoff = pgoff; } So figuring out where this came from: No C reproducer but a syzbot reproducer: https://syzkaller.appspot.com/text?tag=ReproSyz&x=176d5949580000 Decoding the flags and abstracting things a bit: -> mremap(old_address=ptr, old_size=0x1000, new_size=0x400000, flags=MREMAP_MAYMOVE | MREMAP_FIXED, new_address=ptr2); mremap(old_address=ptr2, old_size=0x600002, new_size=0x600002, flags=MREMAP_MAYMOVE | MREMAP_FIXED | MREMAP_DONTUNMAP, new_address=ptr2 + 0xa00000); munmap(<0x2000 offset into ptr2>, 0x4000); So MREMAP_DONTUNMAP is a giant red-flag as it introduces unexpected possibly weird behaviour. If we look back to the assert it's that an unfaulted, pure anonymous, VMA has pgoff != vma->vm_start >> PAGE_SHIFT. Looking at dontunmap_complete(): static void dontunmap_complete(struct vma_remap_struct *vrm, struct vm_area_struct *new_vma) { ... /* * anon_vma links of the old vma is no longer needed after its page * table has been moved. */ if (new_vma != vrm->vma && start == old_start && end == old_end) unlink_anon_vmas(vrm->vma); } } Essentially - if the VMA was cleanly copied and not merged with itself or another VMA, then call unlink_anon_vmas(). And unlink_anon_vmas() sets vma->anon_vma = NULL. Assuming the VMA was faulted in before the first mremap() call then vma->vm_pgoff will be equal to ptr >> PAGE_SHIFT not ptr2 >> PAGE_SHIFT. And now it has vma->anon_vma == NULL (unfaulted) and vma->vm_pgoff is incorrect. So we have an unfortunate case of a VMA that is anonymous, unfaulted, but has an entirely incorrect vma->vm_pgoff. So this is a bug in the kernel and exactly what the assert is for :) The assert is triggered on the unmap as explored below... In essence - MREMAP_DONTUNMAP is a unique case where a faulted VMA can become unfaulted (let's not dwell on that too long :) but it's not properly resetting its state when it does so. I'll send a fix. On Thu, Aug 20, 2026 at 03:52:43PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 4477a78374a5 Add linux-next specific files for 20260814 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=137fc679580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9b32a36dd637b06f > dashboard link: https://syzkaller.appspot.com/bug?extid=f12658786a4153df5113 > compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=176d5949580000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/994c1c8c560e/disk-4477a783.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/cd54543d69ae/vmlinux-4477a783.xz > kernel image: https://storage.googleapis.com/syzbot-assets/407cdf8f3fc2/bzImage-4477a783.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com > > ------------[ cut here ]------------ > pgoff != vma->vm_start >> 12 > WARNING: mm/vma.h:277 at assert_sane_pgoff mm/vma.h:277 [inline], CPU#1: syz.0.17/5809 > WARNING: mm/vma.h:277 at vma_set_pgoff+0x246/0x2d0 mm/vma.h:283, CPU#1: syz.0.17/5809 The assert fires due to analysis above. > Modules linked in: > CPU: 1 UID: 0 PID: 5809 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 > RIP: 0010:assert_sane_pgoff mm/vma.h:277 [inline] > RIP: 0010:vma_set_pgoff+0x246/0x2d0 mm/vma.h:283 > Code: 0b 90 e9 d5 fe ff ff e8 a8 ed a0 ff 4c 89 f7 e8 50 5b 01 ff c6 05 b6 05 3c 0e 01 90 0f 0b 90 e9 fe fe ff ff e8 8b ed a0 ff 90 <0f> 0b 90 eb 9d 44 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c eb fd ff ff > RSP: 0018:ffffc900035ef748 EFLAGS: 00010293 > RAX: ffffffff8226cfa5 RBX: 0000000200000a98 RCX: ffff88802733ddc0 > RDX: 0000000000000000 RSI: 0000000200000002 RDI: 0000000200000a98 > RBP: 0000000000000007 R08: ffff888076188bc3 R09: 1ffff1100ec31178 > R10: dffffc0000000000 R11: ffffed100ec31179 R12: 0000000000000001 > R13: dffffc0000000000 R14: ffff888076188b40 R15: 0000000200000002 > FS: 0000555576422500(0000) GS:ffff888124df8000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f9f85a70000 CR3: 000000007cdfc000 CR4: 00000000003526f0 > Call Trace: > > vma_add_pgoff+0x1a8/0x570 mm/vma.h:314 And that invokes vma_add_pgoff() -> vma_set_pgoff()... > __split_vma+0x89e/0xa60 mm/vma.c:607 The unmap triggers a split... > vms_gather_munmap_vmas+0x322/0x1370 mm/vma.c:1507 > do_vmi_align_munmap+0x2b4/0x4b0 mm/vma.c:1675 > do_vmi_munmap+0x252/0x2d0 mm/vma.c:1732 > __vm_munmap+0x241/0x3e0 mm/vma.c:3390 > __do_sys_munmap mm/mmap.c:1094 [inline] > __se_sys_munmap mm/mmap.c:1091 [inline] > __x64_sys_munmap+0x60/0x70 mm/mmap.c:1091 > do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] > do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f9f85b9e0d9 > Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fff50d2f8f8 EFLAGS: 00000246 ORIG_RAX: 000000000000000b > RAX: ffffffffffffffda RBX: 00007f9f85e25fa0 RCX: 00007f9f85b9e0d9 > RDX: 0000000000000000 RSI: 0000000000004000 RDI: 0000200000002000 > RBP: 00007f9f85c35024 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 00007f9f85e25fac R14: 00007f9f85e25fa0 R15: 00007f9f85e25fa0 > > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > If the report is already addressed, let syzbot know by replying with: > #syz fix: exact-commit-title > > If you want syzbot to run the reproducer, reply with: > #syz test: git://repo/address.git branch-or-commit-hash > If you attach or paste a git patch, syzbot will apply it before testing. > > If you want to overwrite report's subsystems, reply with: > #syz set subsystems: new-subsystem > (See the list of subsystem names on the web dashboard) > > If the report is a duplicate of another one, reply with: > #syz dup: exact-subject-of-another-report > > If you want to undo deduplication, reply with: > #syz undup -- Cheers, Lorenzo