[syzbot] [mm?] WARNING in vma_set_pgoff

[syzbot] [mm?] WARNING in vma_set_pgoff

[syzbot]

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
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
 __split_vma+0x89e/0xa60 mm/vma.c:607
 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

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

[Lorenzo Stoakes (ARM)]

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

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    89a312991dc6 Merge tag 'cifs-fixes-7.3-rc2' of https://git..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=101ab0f9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=5e4e3a0e188a497e
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
userspace arch: i386
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=151ec39e580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1761ef79580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9e57f69218a4/disk-89a31299.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c6ae7c71d018/vmlinux-89a31299.xz
kernel image: https://storage.googleapis.com/syzbot-assets/82fb8eee8abf/bzImage-89a31299.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/5876
WARNING: mm/vma.h:277 at vma_set_pgoff+0x246/0x2d0 mm/vma.h:283, CPU#1: syz.0.17/5876
Modules linked in:
CPU: 1 UID: 0 PID: 5876 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 d8 99 9f ff 4c 89 f7 e8 30 09 00 ff c6 05 5d 78 3b 0e 01 90 0f 0b 90 e9 fe fe ff ff e8 bb 99 9f 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:ffffc900032af448 EFLAGS: 00010293
RAX: ffffffff82282165 RBX: 0000000000080004 RCX: ffff8880124c8000
RDX: 0000000000000000 RSI: 0000000000080ffe RDI: 0000000000080004
RBP: 0000000000000007 R08: ffff8880734021c3 R09: 1ffff1100e680438
R10: dffffc0000000000 R11: ffffed100e680439 R12: 0000000000000001
R13: dffffc0000000000 R14: ffff888073402140 R15: 0000000000080ffe
FS:  0000000000000000(0000) GS:ffff888124dda000(0063) knlGS:00000000576bb480
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f7203200 CR3: 0000000079238000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 vma_add_pgoff+0x1a8/0x570 mm/vma.h:314
 __split_vma+0x89e/0xa60 mm/vma.c:607
 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
 shrink_vma mm/mremap.c:1421 [inline]
 mremap_at+0x233/0xba0 mm/mremap.c:1652
 do_mremap mm/mremap.c:2008 [inline]
 __do_sys_mremap mm/mremap.c:2064 [inline]
 __se_sys_mremap+0xf9f/0x12d0 mm/mremap.c:2032
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:79 [inline]
 __do_fast_syscall_32+0x27a/0x6a0 arch/x86/entry/syscall_32.c:291
 do_fast_syscall_32+0x33/0x70 arch/x86/entry/syscall_32.c:316
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
RIP: 0023:0xf7ff70ec
Code: 90 85 d2 74 0a 89 ce 81 e6 ff 0f 00 00 89 32 85 c0 74 05 c1 e9 0c 89 08 31 c0 5e 5d c3 90 0f 1f 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 58 b8
RSP: 002b:00000000ff97fafc EFLAGS: 00000206 ORIG_RAX: 00000000000000a3
RAX: ffffffffffffffda RBX: 0000000080ffd000 RCX: 0000000000002000
RDX: 0000000000001000 RSI: 0000000000000000 RDI: 0000000080ffe000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
----------------
Code disassembly (best guess):
   0:	90                   	nop
   1:	85 d2                	test   %edx,%edx
   3:	74 0a                	je     0xf
   5:	89 ce                	mov    %ecx,%esi
   7:	81 e6 ff 0f 00 00    	and    $0xfff,%esi
   d:	89 32                	mov    %esi,(%rdx)
   f:	85 c0                	test   %eax,%eax
  11:	74 05                	je     0x18
  13:	c1 e9 0c             	shr    $0xc,%ecx
  16:	89 08                	mov    %ecx,(%rax)
  18:	31 c0                	xor    %eax,%eax
  1a:	5e                   	pop    %rsi
  1b:	5d                   	pop    %rbp
  1c:	c3                   	ret
  1d:	90                   	nop
  1e:	0f 1f 00             	nopl   (%rax)
  21:	51                   	push   %rcx
  22:	52                   	push   %rdx
  23:	55                   	push   %rbp
  24:	89 e5                	mov    %esp,%ebp
  26:	0f 34                	sysenter
  28:	cd 80                	int    $0x80
* 2a:	5d                   	pop    %rbp <-- trapping instruction
  2b:	5a                   	pop    %rdx
  2c:	59                   	pop    %rcx
  2d:	c3                   	ret
  2e:	90                   	nop
  2f:	90                   	nop
  30:	90                   	nop
  31:	90                   	nop
  32:	90                   	nop
  33:	90                   	nop
  34:	90                   	nop
  35:	90                   	nop
  36:	90                   	nop
  37:	90                   	nop
  38:	90                   	nop
  39:	90                   	nop
  3a:	90                   	nop
  3b:	90                   	nop
  3c:	90                   	nop
  3d:	90                   	nop
  3e:	58                   	pop    %rax
  3f:	b8                   	.byte 0xb8


---
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.

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

[Andrew Morton]

On Wed, 02 Sep 2026 14:35:38 -0700 syzbot <syzbot+f12658786a4153df5113@syzkaller.appspotmail.com> wrote:

> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    89a312991dc6 Merge tag 'cifs-fixes-7.3-rc2' of https://git..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=101ab0f9580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5e4e3a0e188a497e
> 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
> userspace arch: i386
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=151ec39e580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1761ef79580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/9e57f69218a4/disk-89a31299.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c6ae7c71d018/vmlinux-89a31299.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/82fb8eee8abf/bzImage-89a31299.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com

Thanks.

> ------------[ 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/5876
> WARNING: mm/vma.h:277 at vma_set_pgoff+0x246/0x2d0 mm/vma.h:283, CPU#1: syz.0.17/5876

AI tells me Lorenzo already fixed this with "mm/mremap: reset unfaulted
VMA page offset for MREMAP_DONTUNMAP".  This is presently in
mm-hotfixes-unstable so I'll send it in to Linus next week.

Err, make that this week.


#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP
Date: Tue, 25 Aug 2026 08:55:26 +0100

Uniquely an mremap() invocation using the MREMAP_DONTUNMAP flag can reset
a faulted VMA into an unfaulted one.

It does so after the page tables have been moved to the copied VMA with
MREMAP_DONTUNMAP leaving the old VMA in place which is naturally unfaulted
as the page tables it had are no longer present.

However, in doing so, it violates the invariant that the anonymous page
offset of an unfaulted VMA is vma->vm_start >> PAGE_SHIFT.

This is because a VMA may have been faulted in, mremap()'d (causing a
delta between its page offset and vma->vm_start >> PAGE_SHIFT), and then
mremap()'d again with MREMAP_DONTUNMAP resulting in the unfaulting.

This condition is a violation of a fundamental assumption in mm, but now
also triggers an assert in assert_sane_pgoff() which explicitly checks for
this condition.

Correct it by resetting the VMA's page offset at the point of completing
the MREMAP_DONTUNMAP operation.

Link: https://lore.kernel.org/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org
Fixes: 1583aa278f5f ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success")
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a87853b.ae6ddae5.3da009.0023.GAE@google.com/
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Reviewed-by: Kunwu Chan <kunwu.chan@gmail.com>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Cc: Jann Horn <jannh@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Li Xinhai <lixinhai.lxh@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/mremap.c |   22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

--- a/mm/mremap.c~mm-mremap-reset-unfaulted-vma-page-offset-for-mremap_dontunmap
+++ a/mm/mremap.c
@@ -1331,18 +1331,30 @@ static void dontunmap_complete(struct vm
 {
 	unsigned long start = vrm->addr;
 	unsigned long end = vrm->addr + vrm->old_len;
-	unsigned long old_start = vrm->vma->vm_start;
-	unsigned long old_end = vrm->vma->vm_end;
+	struct vm_area_struct *vma = vrm->vma;
+	unsigned long old_start = vma->vm_start;
+	unsigned long old_end = vma->vm_end;
 
 	/* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
-	vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
+	vma_clear_flags_mask(vma, VMA_LOCKED_MASK);
 
 	/*
 	 * 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);
+	if (new_vma != vma && start == old_start && end == old_end) {
+		const pgoff_t pgoff_unfaulted = vma->vm_start >> PAGE_SHIFT;
+
+		unlink_anon_vmas(vma);
+		/*
+		 * The VMA is now unfaulted and it is an invariant that
+		 * unfaulted anonymous VMAs have page offset equal to
+		 * vma->vm_start >> PAGE_SHIFT.
+		 */
+		vma_set_anon_pgoff(vma, pgoff_unfaulted);
+		if (vma_is_anonymous(vma) && !vma->vm_file)
+			vma_set_pgoff(vma, pgoff_unfaulted);
+	}
 
 	/* Because we won't unmap we don't need to touch locked_vm. */
 }
_

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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com
Tested-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com

Tested on:

commit:         940de590 Merge tag 'hardening-v7.3-rc2' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=147d1f79580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=5e4e3a0e188a497e
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
userspace arch: i386
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16b190f9580000

Note: testing is done by a robot and is best-effort only.

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

[Lorenzo Stoakes (ARM)]

On Thu, Sep 03, 2026 at 12:35:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
>
> Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com
> Tested-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com

I suppose we can sling this on the patch Andrew? :)

I did mark the 2nd one dup I'm not sure why we're seeing another duplicate.

>
> Tested on:
>
> commit:         940de590 Merge tag 'hardening-v7.3-rc2' of git://git.k..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=147d1f79580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5e4e3a0e188a497e
> 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
> userspace arch: i386
> patch:          https://syzkaller.appspot.com/x/patch.diff?x=16b190f9580000
>
> Note: testing is done by a robot and is best-effort only.

--
Cheers, Lorenzo