[syzbot] [mm?] WARNING in unlink_anon_vmas (2)

[syzbot] [mm?] WARNING in unlink_anon_vmas (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    b775e489bec7 Add linux-next specific files for 20260114
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15dbc444580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2dcf53f0a51185
dashboard link: https://syzkaller.appspot.com/bug?extid=c27fa543e10a45d4e149
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17070522580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1683f99a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5e077e7eafdc/disk-b775e489.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ea69aef6ee56/vmlinux-b775e489.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b8b6986280d1/bzImage-b775e489.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c27fa543e10a45d4e149@syzkaller.appspotmail.com

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f16655e5fa0 R14: 00007f16655e5fa0 R15: 0000000000000002
 </TASK>
------------[ cut here ]------------
WARNING: mm/rmap.c:480 at unlink_anon_vmas+0x701/0x730 mm/rmap.c:480, CPU#0: syz.0.20/5987
Modules linked in:
CPU: 0 UID: 0 PID: 5987 Comm: syz.0.20 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:unlink_anon_vmas+0x701/0x730 mm/rmap.c:480
Code: ac ff 48 83 c4 40 5b 41 5c 41 5d 41 5e 41 5f 5d e9 84 df 56 09 cc e8 8e ed ac ff 90 0f 0b 90 e9 e2 f9 ff ff e8 80 ed ac ff 90 <0f> 0b 90 eb d3 48 c7 c1 10 ab c4 8f 80 e1 07 80 c1 03 38 c1 0f 8c
RSP: 0018:ffffc900033676c0 EFLAGS: 00010293
RAX: ffffffff821460b0 RBX: dffffc0000000000 RCX: ffff88802a773c80
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000001 R08: ffffffff8fc47af7 R09: 1ffffffff1f88f5e
R10: dffffc0000000000 R11: fffffbfff1f88f5f R12: 1ffff110062fbaa8
R13: ffff888027aad900 R14: ffff8880317dd510 R15: ffff8880317dd530
FS:  0000555592787500(0000) GS:ffff8881259ad000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f166526615a CR3: 000000002f0cc000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 anon_vma_fork+0x4b9/0x500 mm/rmap.c:438
 dup_mmap+0x954/0x1b80 mm/mmap.c:1790
 dup_mm kernel/fork.c:1529 [inline]
 copy_mm+0x13c/0x4b0 kernel/fork.c:1581
 copy_process+0x1812/0x3ba0 kernel/fork.c:2218
 kernel_clone+0x21e/0x820 kernel/fork.c:2648
 __do_sys_clone3 kernel/fork.c:2950 [inline]
 __se_sys_clone3+0x256/0x2d0 kernel/fork.c:2929
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f166538f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe55f4df08 EFLAGS: 00000246 ORIG_RAX: 00000000000001b3
RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f166538f749
RDX: 00007ffe55f4df20 RSI: 0000000000000058 RDI: 00007ffe55f4df20
RBP: 00007ffe55f4e090 R08: 0000000000000000 R09: 0000000000000058
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f16655e5fa0 R14: 00007f16655e5fa0 R15: 0000000000000002
 </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

Forwarded: [PATCH] mm/rmap: fix unlink_anon_vmas() handling of error case from anon_vma_fork

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/rmap: fix unlink_anon_vmas() handling of error case from anon_vma_fork
Author: kartikey406@gmail.com

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

When anon_vma_fork() encounters a memory allocation failure after
anon_vma_clone() has succeeded, unlink_anon_vmas() is called with
vma->anon_vma being NULL but the anon_vma_chain populated with entries
that are present in the anon_vma interval trees.

This happens in the following sequence:
1. anon_vma_clone() succeeds, populating vma->anon_vma_chain and
   inserting entries into interval trees
2. maybe_reuse_anon_vma() does not set vma->anon_vma because reuse
   conditions are not met (common case for active processes)
3. anon_vma_alloc() or anon_vma_chain_alloc() fails due to memory
   pressure
4. Error path invokes unlink_anon_vmas() with vma->anon_vma == NULL

The existing code triggered VM_WARN_ON_ONCE and returned without
performing cleanup, leaving entries in interval trees and causing
memory leaks.

Fix this by detecting the condition and properly cleaning up:
- Iterate through the populated chain
- Lock each anon_vma
- Remove entries from interval trees
- Unlock and free chain entries

This prevents both the warning and the resource leaks.

Reported-by: syzbot+c27fa543e10a45d4e149@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=c27fa543e10a45d4e149
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 mm/rmap.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index f13480cb9f2e..acc8df6ad4a7 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -477,7 +477,31 @@ void unlink_anon_vmas(struct vm_area_struct *vma)
 
 	/* Unfaulted is a no-op. */
 	if (!active_anon_vma) {
-		VM_WARN_ON_ONCE(!list_empty(&vma->anon_vma_chain));
+		/*
+		 * Handle anon_vma_fork() error path where anon_vma_clone()
+		 * succeeded and populated the chain (with entries in interval
+		 * trees), but maybe_reuse_anon_vma() didn't set vma->anon_vma
+		 * because reuse conditions weren't met, and a later allocation
+		 * failed before we could allocate and assign a new anon_vma.
+		 *
+		 * We must properly remove entries from interval trees before
+		 * freeing to avoid leaving dangling pointers.
+		 */
+		if (!list_empty(&vma->anon_vma_chain)) {
+			struct anon_vma_chain *avc, *next;
+
+			list_for_each_entry_safe(avc, next, &vma->anon_vma_chain,
+						same_vma) {
+				struct anon_vma *anon_vma = avc->anon_vma;
+
+				anon_vma_lock_write(anon_vma);
+				anon_vma_interval_tree_remove(avc, &anon_vma->rb_root);
+				anon_vma_unlock_write(anon_vma);
+				list_del(&avc->same_vma);
+				anon_vma_chain_free(avc);
+			}
+		}
+
 		return;
 	}
 
-- 
2.43.0

Forwarded: [PATCH] mm/rmap: fix unlink_anon_vmas() handling of error case from anon_vma_fork

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/rmap: fix unlink_anon_vmas() handling of error case from anon_vma_fork
Author: kartikey406@gmail.com

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

When anon_vma_fork() encounters a memory allocation failure after
anon_vma_clone() has succeeded, unlink_anon_vmas() is called with
vma->anon_vma being NULL but the anon_vma_chain populated with entries
that are present in the anon_vma interval trees.

This happens in the following sequence:
1. anon_vma_clone() succeeds, populating vma->anon_vma_chain and
   inserting entries into interval trees
2. maybe_reuse_anon_vma() does not set vma->anon_vma because reuse
   conditions are not met (common case for active processes)
3. anon_vma_alloc() or anon_vma_chain_alloc() fails due to memory
   pressure
4. Error path invokes unlink_anon_vmas() with vma->anon_vma == NULL

The existing code triggered VM_WARN_ON_ONCE and returned without
performing cleanup, leaving entries in interval trees and causing
memory leaks.

Fix this by detecting the condition and properly cleaning up:
- Iterate through the populated chain
- Lock each anon_vma
- Remove entries from interval trees
- Unlock and free chain entries

This prevents both the warning and the resource leaks.

Reported-by: syzbot+c27fa543e10a45d4e149@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=c27fa543e10a45d4e149
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 mm/rmap.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index f13480cb9f2e..acc8df6ad4a7 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -477,7 +477,31 @@ void unlink_anon_vmas(struct vm_area_struct *vma)
 
 	/* Unfaulted is a no-op. */
 	if (!active_anon_vma) {
-		VM_WARN_ON_ONCE(!list_empty(&vma->anon_vma_chain));
+		/*
+		 * Handle anon_vma_fork() error path where anon_vma_clone()
+		 * succeeded and populated the chain (with entries in interval
+		 * trees), but maybe_reuse_anon_vma() didn't set vma->anon_vma
+		 * because reuse conditions weren't met, and a later allocation
+		 * failed before we could allocate and assign a new anon_vma.
+		 *
+		 * We must properly remove entries from interval trees before
+		 * freeing to avoid leaving dangling pointers.
+		 */
+		if (!list_empty(&vma->anon_vma_chain)) {
+			struct anon_vma_chain *avc, *next;
+
+			list_for_each_entry_safe(avc, next, &vma->anon_vma_chain,
+						same_vma) {
+				struct anon_vma *anon_vma = avc->anon_vma;
+
+				anon_vma_lock_write(anon_vma);
+				anon_vma_interval_tree_remove(avc, &anon_vma->rb_root);
+				anon_vma_unlock_write(anon_vma);
+				list_del(&avc->same_vma);
+				anon_vma_chain_free(avc);
+			}
+		}
+
 		return;
 	}
 
-- 
2.43.0

Re: [syzbot] [mm?] WARNING in unlink_anon_vmas (2)

[Lorenzo Stoakes]

On Sat, Jan 17, 2026 at 11:30:24PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    b775e489bec7 Add linux-next specific files for 20260114
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15dbc444580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=2dcf53f0a51185
> dashboard link: https://syzkaller.appspot.com/bug?extid=c27fa543e10a45d4e149
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17070522580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1683f99a580000

Thanks, of course being a fault injection thing it's hard to repro :))

>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/5e077e7eafdc/disk-b775e489.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/ea69aef6ee56/vmlinux-b775e489.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/b8b6986280d1/bzImage-b775e489.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c27fa543e10a45d4e149@syzkaller.appspotmail.com
>
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
> R13: 00007f16655e5fa0 R14: 00007f16655e5fa0 R15: 0000000000000002
>  </TASK>
> ------------[ cut here ]------------
> WARNING: mm/rmap.c:480 at unlink_anon_vmas+0x701/0x730 mm/rmap.c:480, CPU#0: syz.0.20/5987
> Modules linked in:
> CPU: 0 UID: 0 PID: 5987 Comm: syz.0.20 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> RIP: 0010:unlink_anon_vmas+0x701/0x730 mm/rmap.c:480
> Code: ac ff 48 83 c4 40 5b 41 5c 41 5d 41 5e 41 5f 5d e9 84 df 56 09 cc e8 8e ed ac ff 90 0f 0b 90 e9 e2 f9 ff ff e8 80 ed ac ff 90 <0f> 0b 90 eb d3 48 c7 c1 10 ab c4 8f 80 e1 07 80 c1 03 38 c1 0f 8c
> RSP: 0018:ffffc900033676c0 EFLAGS: 00010293
> RAX: ffffffff821460b0 RBX: dffffc0000000000 RCX: ffff88802a773c80
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
> RBP: 0000000000000001 R08: ffffffff8fc47af7 R09: 1ffffffff1f88f5e
> R10: dffffc0000000000 R11: fffffbfff1f88f5f R12: 1ffff110062fbaa8
> R13: ffff888027aad900 R14: ffff8880317dd510 R15: ffff8880317dd530
> FS:  0000555592787500(0000) GS:ffff8881259ad000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f166526615a CR3: 000000002f0cc000 CR4: 00000000003526f0
> Call Trace:
>  <TASK>

Yup this is a nasty additional and impossible-to-hit-in-practice case the
series didn't account for, this time in anon_vma_fork().

Very annoyingly, it violates assumptions made because we try to free up a
partially set up anon_vma.

I'll rework my series + respin to account for this.

Cheers, Lorenzo

>  anon_vma_fork+0x4b9/0x500 mm/rmap.c:438
>  dup_mmap+0x954/0x1b80 mm/mmap.c:1790
>  dup_mm kernel/fork.c:1529 [inline]
>  copy_mm+0x13c/0x4b0 kernel/fork.c:1581
>  copy_process+0x1812/0x3ba0 kernel/fork.c:2218
>  kernel_clone+0x21e/0x820 kernel/fork.c:2648
>  __do_sys_clone3 kernel/fork.c:2950 [inline]
>  __se_sys_clone3+0x256/0x2d0 kernel/fork.c:2929
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f166538f749
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffe55f4df08 EFLAGS: 00000246 ORIG_RAX: 00000000000001b3
> RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f166538f749
> RDX: 00007ffe55f4df20 RSI: 0000000000000058 RDI: 00007ffe55f4df20
> RBP: 00007ffe55f4e090 R08: 0000000000000000 R09: 0000000000000058
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
> R13: 00007f16655e5fa0 R14: 00007f16655e5fa0 R15: 0000000000000002
>  </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