Re: [syzbot] [mm?] WARNING in vma_set_pgoff

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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:
>  <TASK>
>  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
>  </TASK>
>
>
> ---
> 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