* [syzbot] [mm?] WARNING in vma_merge_existing_range
@ 2025-01-01 4:50 syzbot
2025-01-02 10:25 ` Lorenzo Stoakes
0 siblings, 1 reply; 8+ messages in thread
From: syzbot @ 2025-01-01 4:50 UTC (permalink / raw)
To: Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
lorenzo.stoakes, syzkaller-bugs, vbabka
Hello,
syzbot found the following issue on:
HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: i386
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
------------[ cut here ]------------
WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
Modules linked in:
CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
Call Trace:
<TASK>
vma_modify+0x41/0x330 mm/vma.c:1514
vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
madvise_vma_behavior mm/madvise.c:1325 [inline]
madvise_walk_vmas mm/madvise.c:1497 [inline]
do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
__do_sys_madvise mm/madvise.c:1700 [inline]
__se_sys_madvise mm/madvise.c:1698 [inline]
__ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
__do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
RIP: 0023:0xf7fc2579
Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
----------------
Code disassembly (best guess), 2 bytes skipped:
0: 10 06 adc %al,(%rsi)
2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
6: 10 07 adc %al,(%rdi)
8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
c: 10 08 adc %cl,(%rax)
e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
1e: 00 51 52 add %dl,0x52(%rcx)
21: 55 push %rbp
22: 89 e5 mov %esp,%ebp
24: 0f 34 sysenter
26: cd 80 int $0x80
* 28: 5d pop %rbp <-- trapping instruction
29: 5a pop %rdx
2a: 59 pop %rcx
2b: c3 ret
2c: 90 nop
2d: 90 nop
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
---
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 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-01 4:50 [syzbot] [mm?] WARNING in vma_merge_existing_range syzbot
@ 2025-01-02 10:25 ` Lorenzo Stoakes
2025-01-02 11:34 ` Lorenzo Stoakes
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Lorenzo Stoakes @ 2025-01-02 10:25 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
Happy new year!
On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: i386
Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
userland, 64-bit kernel?
>
> Unfortunately, I don't have any reproducer for this issue yet.
Hmm. Racey thing?
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
>
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> </TASK>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
It'd be nice if syzbot could actually print the code that generates the
warning :) a nice-to-have perhaps.
This is:
VM_WARN_ON(start >= end);
I suspect start == end, because start > end would be some drastic and
god-awful bug.
> Modules linked in:
> CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
Be useful to get the kernel disassembly too :)
Best guess wranging a python script and objdump:
0: e8 20 24 0f 00 call 0xf2425
5: 4d 2b 7d 00 sub 0x0(%r13),%r15
9: 4d 89 ec mov %r13,%r12
c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
11: e9 7f 01 00 00 jmp 0x195
16: e8 3a bc a8 ff call 0xffffffffffa8bc55
1b: 90 nop
1c: 0f 0b ud2
1e: 90 nop
1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc
24: e8 2c bc a8 ff call 0xffffffffffa8bc55
29: 90 nop
2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction...
2c: 90 nop
2d: e9 0e f2 ff ff jmp 0xfffffffffffff240
32: e8 1e bc a8 ff call 0xffffffffffa8bc55
37: 90 nop
38: 0f 0b ud2
3a: 90 nop
3b: 4d 85 ed test %r13,%r13
3e: 0f .byte 0xf
3f: 85 .byte 0x85
Yeah this might be a mix of data and code somehow or just garbage? Not sure
there's anything discernable there unfortunately.
> RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
> RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
> RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
> RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
> R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
> R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
> FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
> Call Trace:
> <TASK>
> vma_modify+0x41/0x330 mm/vma.c:1514
Just passes through start, end (in vmg).
> vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
Just passes through start, end.
> madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
Just passes through start, end.
This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK,
MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP,
MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE.
Yeah we need better error handling here, because this report is just giving
us very little to go on especially for a non-repro. Will add to TODO.
> madvise_vma_behavior mm/madvise.c:1325 [inline]
Just passes through start, end.
> madvise_walk_vmas mm/madvise.c:1497 [inline]
OK here we find VMAs and walk them.
We explicitly check for start >= send if start < vma->vm_start.
I wonder if the visit() call is splitting the VMA which confuses the logic
here.
s e
| |
v v
|-------------|
| |
|-------------|
Split:
s e
| |
v v
|--------|----|
| | |
|--------|----|
prev = this VMA.
if (prev && start < prev->vm_end)
start = prev->vm_end;
So we end up with:
s,e
|
v
|--------|----|
| | |
|--------|----|
tmp = vma->vm_end;
if (end < tmp)
tmp = end;
That tmp assignment will reinstate the broken end
And... boom.
Let me check this out and see if I can trigger it.
I may be missing some safeguard that prevents this...
> do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
Here we explicitly check for start >= end:
end = start + len;
if (end < start)
return -EINVAL;
if (end == start)
return 0;
So overflow is accounted for also. But since this is a 64-bit kernel not
really a concern.
> __do_sys_madvise mm/madvise.c:1700 [inline]
> __se_sys_madvise mm/madvise.c:1698 [inline]
> __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
> do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
> __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
> do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
> entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> RIP: 0023:0xf7fc2579
> Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
> RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
> RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
> RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> </TASK>
> ----------------
> Code disassembly (best guess), 2 bytes skipped:
> 0: 10 06 adc %al,(%rsi)
> 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
> 6: 10 07 adc %al,(%rdi)
> 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
> c: 10 08 adc %cl,(%rax)
> e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
> 1e: 00 51 52 add %dl,0x52(%rcx)
> 21: 55 push %rbp
> 22: 89 e5 mov %esp,%ebp
> 24: 0f 34 sysenter
> 26: cd 80 int $0x80
> * 28: 5d pop %rbp <-- trapping instruction
> 29: 5a pop %rdx
> 2a: 59 pop %rcx
> 2b: c3 ret
> 2c: 90 nop
> 2d: 90 nop
> 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
>
>
> ---
> 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 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-02 10:25 ` Lorenzo Stoakes
@ 2025-01-02 11:34 ` Lorenzo Stoakes
2025-01-02 17:19 ` Aleksandr Nogikh
2025-01-02 17:31 ` Matthew Wilcox
2 siblings, 0 replies; 8+ messages in thread
From: Lorenzo Stoakes @ 2025-01-02 11:34 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
TL;DR:
There's not enough to go on in this report as far as I can tell. I will do
what I can writing some general tests to explore edge cases but this is
really, really odd + fact it doesn't repro is odder. And this report just
doesn't have enough data (I will work on seeing if we can provide more...).
On Thu, Jan 02, 2025 at 10:25:49AM +0000, Lorenzo Stoakes wrote:
> Happy new year!
>
> On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > userspace arch: i386
>
> Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> userland, 64-bit kernel?
>
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
>
> Hmm. Racey thing?
>
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
> >
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
>
> It'd be nice if syzbot could actually print the code that generates the
> warning :) a nice-to-have perhaps.
>
> This is:
>
> VM_WARN_ON(start >= end);
>
> I suspect start == end, because start > end would be some drastic and
> god-awful bug.
>
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
>
> Be useful to get the kernel disassembly too :)
>
> Best guess wranging a python script and objdump:
>
> 0: e8 20 24 0f 00 call 0xf2425
> 5: 4d 2b 7d 00 sub 0x0(%r13),%r15
> 9: 4d 89 ec mov %r13,%r12
> c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
> 11: e9 7f 01 00 00 jmp 0x195
> 16: e8 3a bc a8 ff call 0xffffffffffa8bc55
> 1b: 90 nop
> 1c: 0f 0b ud2
> 1e: 90 nop
> 1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc
> 24: e8 2c bc a8 ff call 0xffffffffffa8bc55
> 29: 90 nop
> 2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction...
> 2c: 90 nop
> 2d: e9 0e f2 ff ff jmp 0xfffffffffffff240
> 32: e8 1e bc a8 ff call 0xffffffffffa8bc55
> 37: 90 nop
> 38: 0f 0b ud2
> 3a: 90 nop
> 3b: 4d 85 ed test %r13,%r13
> 3e: 0f .byte 0xf
> 3f: 85 .byte 0x85
>
> Yeah this might be a mix of data and code somehow or just garbage? Not sure
> there's anything discernable there unfortunately.
>
> > RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
> > RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
> > RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
> > RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
> > R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
> > R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
> > FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
> > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> > CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
>
> > Call Trace:
> > <TASK>
> > vma_modify+0x41/0x330 mm/vma.c:1514
>
> Just passes through start, end (in vmg).
>
> > vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
>
> Just passes through start, end.
>
> > madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
>
> Just passes through start, end.
>
> This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK,
> MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP,
> MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE.
Actually could also be called via... incredibly... prctl_set_vma() which invokes
madvise_set_anon_name()...
>
> Yeah we need better error handling here, because this report is just giving
> us very little to go on especially for a non-repro. Will add to TODO.
>
> > madvise_vma_behavior mm/madvise.c:1325 [inline]
>
> Just passes through start, end.
>
> > madvise_walk_vmas mm/madvise.c:1497 [inline]
>
> OK here we find VMAs and walk them.
>
> We explicitly check for start >= send if start < vma->vm_start.
>
> I wonder if the visit() call is splitting the VMA which confuses the logic
> here.
>
> s e
> | |
> v v
> |-------------|
> | |
> |-------------|
>
> Split:
>
> s e
> | |
> v v
> |--------|----|
> | | |
> |--------|----|
>
> prev = this VMA.
>
> if (prev && start < prev->vm_end)
> start = prev->vm_end;
>
> So we end up with:
>
>
> s,e
> |
> v
> |--------|----|
> | | |
> |--------|----|
>
> tmp = vma->vm_end;
> if (end < tmp)
> tmp = end;
>
> That tmp assignment will reinstate the broken end
>
> And... boom.
>
> Let me check this out and see if I can trigger it.
>
> I may be missing some safeguard that prevents this...
OK so this case wouldn't happen as we check start >= end at this point.
I will look at adding some test cases around this to see if I can figure out
broken scenarios.
But actually, if this was some structural thing like this, a repro would be
trivial.
There are cases where the mmap lock can be dropped, but none should be invoking
madvise_update_vma().
OK this is really really odd.
The fact there's not a repro suggests something is racing but we hold the mmap
lock so I really can't see how that's possible.
This report is just insufficient to go on really.
I will work on:
a. tests that explore odd scenarios in madvise_walk_vmas().
b. getting better debug data on these asserts.
c. refactoring some of this HIDEOUS madvise() code.
But for now unless we can get a repro not sure there's much we can do.
>
>
> > do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
>
> Here we explicitly check for start >= end:
>
> end = start + len;
> if (end < start)
> return -EINVAL;
>
> if (end == start)
> return 0;
>
> So overflow is accounted for also. But since this is a 64-bit kernel not
> really a concern.
>
> > __do_sys_madvise mm/madvise.c:1700 [inline]
> > __se_sys_madvise mm/madvise.c:1698 [inline]
> > __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
> > do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
> > __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
> > do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
> > entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> > RIP: 0023:0xf7fc2579
> > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
> > RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
> > RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
> > RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> > ----------------
> > Code disassembly (best guess), 2 bytes skipped:
> > 0: 10 06 adc %al,(%rsi)
> > 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
> > 6: 10 07 adc %al,(%rdi)
> > 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
> > c: 10 08 adc %cl,(%rax)
> > e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
> > 1e: 00 51 52 add %dl,0x52(%rcx)
> > 21: 55 push %rbp
> > 22: 89 e5 mov %esp,%ebp
> > 24: 0f 34 sysenter
> > 26: cd 80 int $0x80
> > * 28: 5d pop %rbp <-- trapping instruction
> > 29: 5a pop %rdx
> > 2a: 59 pop %rcx
> > 2b: c3 ret
> > 2c: 90 nop
> > 2d: 90 nop
> > 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
> >
> >
> > ---
> > 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 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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-02 10:25 ` Lorenzo Stoakes
2025-01-02 11:34 ` Lorenzo Stoakes
@ 2025-01-02 17:19 ` Aleksandr Nogikh
2025-01-03 19:08 ` Lorenzo Stoakes
2025-01-07 8:14 ` Dmitry Vyukov
2025-01-02 17:31 ` Matthew Wilcox
2 siblings, 2 replies; 8+ messages in thread
From: Aleksandr Nogikh @ 2025-01-02 17:19 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: syzbot, Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
> Happy new year!
Happy New Year! :)
>
> On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > userspace arch: i386
>
> Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> userland, 64-bit kernel?
Yes, that's a 32-bit userspace binary running on a 64-bit kernel.
>
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
>
> Hmm. Racey thing?
>
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
> >
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
>
> It'd be nice if syzbot could actually print the code that generates the
> warning :) a nice-to-have perhaps.
Thanks for the suggestion!
I've filed https://github.com/google/syzkaller/issues/5654
>
> This is:
>
> VM_WARN_ON(start >= end);
>
> I suspect start == end, because start > end would be some drastic and
> god-awful bug.
>
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
>
> Be useful to get the kernel disassembly too :)
>
> Best guess wranging a python script and objdump:
>
> 0: e8 20 24 0f 00 call 0xf2425
> 5: 4d 2b 7d 00 sub 0x0(%r13),%r15
> 9: 4d 89 ec mov %r13,%r12
> c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
> 11: e9 7f 01 00 00 jmp 0x195
> 16: e8 3a bc a8 ff call 0xffffffffffa8bc55
> 1b: 90 nop
> 1c: 0f 0b ud2
> 1e: 90 nop
> 1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc
> 24: e8 2c bc a8 ff call 0xffffffffffa8bc55
> 29: 90 nop
> 2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction...
> 2c: 90 nop
> 2d: e9 0e f2 ff ff jmp 0xfffffffffffff240
> 32: e8 1e bc a8 ff call 0xffffffffffa8bc55
> 37: 90 nop
> 38: 0f 0b ud2
> 3a: 90 nop
> 3b: 4d 85 ed test %r13,%r13
> 3e: 0f .byte 0xf
> 3f: 85 .byte 0x85
>
> Yeah this might be a mix of data and code somehow or just garbage? Not sure
> there's anything discernable there unfortunately.
Syzbot also did some disassembly at the bottom of the report. I wonder
what's the difference between the two "Code" fields and if there's a
way to automatically select the right one for the disassembly.
>
> > RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
> > RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
> > RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
> > RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
> > R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
> > R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
> > FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
> > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> > CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
>
> > Call Trace:
> > <TASK>
> > vma_modify+0x41/0x330 mm/vma.c:1514
>
> Just passes through start, end (in vmg).
>
> > vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
>
> Just passes through start, end.
>
> > madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
>
> Just passes through start, end.
>
> This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK,
> MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP,
> MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE.
>
> Yeah we need better error handling here, because this report is just giving
> us very little to go on especially for a non-repro. Will add to TODO.
>
> > madvise_vma_behavior mm/madvise.c:1325 [inline]
>
> Just passes through start, end.
>
> > madvise_walk_vmas mm/madvise.c:1497 [inline]
>
> OK here we find VMAs and walk them.
>
> We explicitly check for start >= send if start < vma->vm_start.
>
> I wonder if the visit() call is splitting the VMA which confuses the logic
> here.
>
> s e
> | |
> v v
> |-------------|
> | |
> |-------------|
>
> Split:
>
> s e
> | |
> v v
> |--------|----|
> | | |
> |--------|----|
>
> prev = this VMA.
>
> if (prev && start < prev->vm_end)
> start = prev->vm_end;
>
> So we end up with:
>
>
> s,e
> |
> v
> |--------|----|
> | | |
> |--------|----|
>
> tmp = vma->vm_end;
> if (end < tmp)
> tmp = end;
>
> That tmp assignment will reinstate the broken end
>
> And... boom.
>
> Let me check this out and see if I can trigger it.
>
> I may be missing some safeguard that prevents this...
>
>
> > do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
>
> Here we explicitly check for start >= end:
>
> end = start + len;
> if (end < start)
> return -EINVAL;
>
> if (end == start)
> return 0;
>
> So overflow is accounted for also. But since this is a 64-bit kernel not
> really a concern.
>
> > __do_sys_madvise mm/madvise.c:1700 [inline]
> > __se_sys_madvise mm/madvise.c:1698 [inline]
> > __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
> > do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
> > __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
> > do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
> > entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> > RIP: 0023:0xf7fc2579
> > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
> > RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
> > RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
> > RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> > ----------------
> > Code disassembly (best guess), 2 bytes skipped:
> > 0: 10 06 adc %al,(%rsi)
> > 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
> > 6: 10 07 adc %al,(%rdi)
> > 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
> > c: 10 08 adc %cl,(%rax)
> > e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
> > 1e: 00 51 52 add %dl,0x52(%rcx)
> > 21: 55 push %rbp
> > 22: 89 e5 mov %esp,%ebp
> > 24: 0f 34 sysenter
> > 26: cd 80 int $0x80
> > * 28: 5d pop %rbp <-- trapping instruction
> > 29: 5a pop %rdx
> > 2a: 59 pop %rcx
> > 2b: c3 ret
> > 2c: 90 nop
> > 2d: 90 nop
> > 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
> >
> >
> > ---
> > 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 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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-02 10:25 ` Lorenzo Stoakes
2025-01-02 11:34 ` Lorenzo Stoakes
2025-01-02 17:19 ` Aleksandr Nogikh
@ 2025-01-02 17:31 ` Matthew Wilcox
2 siblings, 0 replies; 8+ messages in thread
From: Matthew Wilcox @ 2025-01-02 17:31 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: syzbot, Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Thu, Jan 02, 2025 at 10:25:49AM +0000, Lorenzo Stoakes wrote:
> It'd be nice if syzbot could actually print the code that generates the
> warning :) a nice-to-have perhaps.
>
> This is:
>
> VM_WARN_ON(start >= end);
>
> I suspect start == end, because start > end would be some drastic and
> god-awful bug.
>
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
>
> Be useful to get the kernel disassembly too :)
>
> Best guess wranging a python script and objdump:
>
> 0: e8 20 24 0f 00 call 0xf2425
> 5: 4d 2b 7d 00 sub 0x0(%r13),%r15
> 9: 4d 89 ec mov %r13,%r12
> c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
> 11: e9 7f 01 00 00 jmp 0x195
> 16: e8 3a bc a8 ff call 0xffffffffffa8bc55
> 1b: 90 nop
> 1c: 0f 0b ud2
> 1e: 90 nop
> 1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc
> 24: e8 2c bc a8 ff call 0xffffffffffa8bc55
> 29: 90 nop
> 2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction...
> 2c: 90 nop
> 2d: e9 0e f2 ff ff jmp 0xfffffffffffff240
> 32: e8 1e bc a8 ff call 0xffffffffffa8bc55
> 37: 90 nop
> 38: 0f 0b ud2
> 3a: 90 nop
> 3b: 4d 85 ed test %r13,%r13
> 3e: 0f .byte 0xf
> 3f: 85 .byte 0x85
>
> Yeah this might be a mix of data and code somehow or just garbage? Not sure
> there's anything discernable there unfortunately.
There's scripts/decodecode which agrees with your hacky script.
Indeed, ud2 is the trapping instruction, but that's expected because
that's how BUG_ON / WARN_ON is implemented.
> > RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
> > RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
> > RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
> > RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
> > R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
> > R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
> > FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
> > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> > CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
I note that RBX, RSI, RDI and R12 all have the same value. That gives
credence to your start == end hypothesis. And it's a plausible
userspace VMA address.
> > Call Trace:
> > <TASK>
> > vma_modify+0x41/0x330 mm/vma.c:1514
>
> Just passes through start, end (in vmg).
>
> > vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
>
> Just passes through start, end.
>
> > madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
>
> Just passes through start, end.
>
> This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK,
> MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP,
> MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE.
>
> Yeah we need better error handling here, because this report is just giving
> us very little to go on especially for a non-repro. Will add to TODO.
>
> > madvise_vma_behavior mm/madvise.c:1325 [inline]
>
> Just passes through start, end.
>
> > madvise_walk_vmas mm/madvise.c:1497 [inline]
>
> OK here we find VMAs and walk them.
>
> We explicitly check for start >= send if start < vma->vm_start.
>
> I wonder if the visit() call is splitting the VMA which confuses the logic
> here.
>
> s e
> | |
> v v
> |-------------|
> | |
> |-------------|
>
> Split:
>
> s e
> | |
> v v
> |--------|----|
> | | |
> |--------|----|
>
> prev = this VMA.
>
> if (prev && start < prev->vm_end)
> start = prev->vm_end;
>
> So we end up with:
>
>
> s,e
> |
> v
> |--------|----|
> | | |
> |--------|----|
>
> tmp = vma->vm_end;
> if (end < tmp)
> tmp = end;
>
> That tmp assignment will reinstate the broken end
>
> And... boom.
>
> Let me check this out and see if I can trigger it.
>
> I may be missing some safeguard that prevents this...
>
>
> > do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
>
> Here we explicitly check for start >= end:
>
> end = start + len;
> if (end < start)
> return -EINVAL;
>
> if (end == start)
> return 0;
>
> So overflow is accounted for also. But since this is a 64-bit kernel not
> really a concern.
>
> > __do_sys_madvise mm/madvise.c:1700 [inline]
> > __se_sys_madvise mm/madvise.c:1698 [inline]
> > __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
> > do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
> > __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
> > do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
> > entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> > RIP: 0023:0xf7fc2579
> > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
> > RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
> > RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
> > RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> > ----------------
> > Code disassembly (best guess), 2 bytes skipped:
> > 0: 10 06 adc %al,(%rsi)
> > 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
> > 6: 10 07 adc %al,(%rdi)
> > 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
> > c: 10 08 adc %cl,(%rax)
> > e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
> > 1e: 00 51 52 add %dl,0x52(%rcx)
> > 21: 55 push %rbp
> > 22: 89 e5 mov %esp,%ebp
> > 24: 0f 34 sysenter
> > 26: cd 80 int $0x80
> > * 28: 5d pop %rbp <-- trapping instruction
> > 29: 5a pop %rdx
> > 2a: 59 pop %rcx
> > 2b: c3 ret
> > 2c: 90 nop
> > 2d: 90 nop
> > 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
> >
> >
> > ---
> > 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 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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-02 17:19 ` Aleksandr Nogikh
@ 2025-01-03 19:08 ` Lorenzo Stoakes
2025-01-07 8:14 ` Dmitry Vyukov
1 sibling, 0 replies; 8+ messages in thread
From: Lorenzo Stoakes @ 2025-01-03 19:08 UTC (permalink / raw)
To: Aleksandr Nogikh
Cc: syzbot, Liam.Howlett, akpm, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Thu, Jan 02, 2025 at 06:19:06PM +0100, Aleksandr Nogikh wrote:
> On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > Happy new year!
>
> Happy New Year! :)
Thanks :)
I am submitting a series to add additional information to the debug output
here by the way, so if this non-repro case recurs we have more to go on.
>
> >
> > On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > userspace arch: i386
> >
> > Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> > userland, 64-bit kernel?
>
> Yes, that's a 32-bit userspace binary running on a 64-bit kernel.
>
> >
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Hmm. Racey thing?
> >
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
> > >
> > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > > </TASK>
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> >
> > It'd be nice if syzbot could actually print the code that generates the
> > warning :) a nice-to-have perhaps.
>
> Thanks for the suggestion!
> I've filed https://github.com/google/syzkaller/issues/5654
Great thanks!
>
> >
> > This is:
> >
> > VM_WARN_ON(start >= end);
> >
> > I suspect start == end, because start > end would be some drastic and
> > god-awful bug.
> >
> > > Modules linked in:
> > > CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > > RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > > Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85
> >
> > Be useful to get the kernel disassembly too :)
> >
> > Best guess wranging a python script and objdump:
> >
> > 0: e8 20 24 0f 00 call 0xf2425
> > 5: 4d 2b 7d 00 sub 0x0(%r13),%r15
> > 9: 4d 89 ec mov %r13,%r12
> > c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
> > 11: e9 7f 01 00 00 jmp 0x195
> > 16: e8 3a bc a8 ff call 0xffffffffffa8bc55
> > 1b: 90 nop
> > 1c: 0f 0b ud2
> > 1e: 90 nop
> > 1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc
> > 24: e8 2c bc a8 ff call 0xffffffffffa8bc55
> > 29: 90 nop
> > 2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction...
> > 2c: 90 nop
> > 2d: e9 0e f2 ff ff jmp 0xfffffffffffff240
> > 32: e8 1e bc a8 ff call 0xffffffffffa8bc55
> > 37: 90 nop
> > 38: 0f 0b ud2
> > 3a: 90 nop
> > 3b: 4d 85 ed test %r13,%r13
> > 3e: 0f .byte 0xf
> > 3f: 85 .byte 0x85
> >
> > Yeah this might be a mix of data and code somehow or just garbage? Not sure
> > there's anything discernable there unfortunately.
>
> Syzbot also did some disassembly at the bottom of the report. I wonder
> what's the difference between the two "Code" fields and if there's a
> way to automatically select the right one for the disassembly.
>
Yeah looks like the userland side (the 2nd code block below). Would be
handy to have kernel bit too.
> >
> > > RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293
> > > RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00
> > > RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000
> > > RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa
> > > R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000
> > > R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0
> > > FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40
> > > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> > > CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0
> >
> > > Call Trace:
> > > <TASK>
> > > vma_modify+0x41/0x330 mm/vma.c:1514
> >
> > Just passes through start, end (in vmg).
> >
> > > vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563
> >
> > Just passes through start, end.
> >
> > > madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159
> >
> > Just passes through start, end.
> >
> > This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK,
> > MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP,
> > MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE.
> >
> > Yeah we need better error handling here, because this report is just giving
> > us very little to go on especially for a non-repro. Will add to TODO.
> >
> > > madvise_vma_behavior mm/madvise.c:1325 [inline]
> >
> > Just passes through start, end.
> >
> > > madvise_walk_vmas mm/madvise.c:1497 [inline]
> >
> > OK here we find VMAs and walk them.
> >
> > We explicitly check for start >= send if start < vma->vm_start.
> >
> > I wonder if the visit() call is splitting the VMA which confuses the logic
> > here.
> >
> > s e
> > | |
> > v v
> > |-------------|
> > | |
> > |-------------|
> >
> > Split:
> >
> > s e
> > | |
> > v v
> > |--------|----|
> > | | |
> > |--------|----|
> >
> > prev = this VMA.
> >
> > if (prev && start < prev->vm_end)
> > start = prev->vm_end;
> >
> > So we end up with:
> >
> >
> > s,e
> > |
> > v
> > |--------|----|
> > | | |
> > |--------|----|
> >
> > tmp = vma->vm_end;
> > if (end < tmp)
> > tmp = end;
> >
> > That tmp assignment will reinstate the broken end
> >
> > And... boom.
> >
> > Let me check this out and see if I can trigger it.
> >
> > I may be missing some safeguard that prevents this...
> >
> >
> > > do_madvise+0x1e64/0x4d10 mm/madvise.c:1684
> >
> > Here we explicitly check for start >= end:
> >
> > end = start + len;
> > if (end < start)
> > return -EINVAL;
> >
> > if (end == start)
> > return 0;
> >
> > So overflow is accounted for also. But since this is a 64-bit kernel not
> > really a concern.
> >
> > > __do_sys_madvise mm/madvise.c:1700 [inline]
> > > __se_sys_madvise mm/madvise.c:1698 [inline]
> > > __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698
> > > do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
> > > __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
> > > do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
> > > entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> > > RIP: 0023:0xf7fc2579
> > > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 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 90 90
> > > RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db
> > > RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000
> > > RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000
> > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > > </TASK>
> > > ----------------
> > > Code disassembly (best guess), 2 bytes skipped:
> > > 0: 10 06 adc %al,(%rsi)
> > > 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi
> > > 6: 10 07 adc %al,(%rdi)
> > > 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi
> > > c: 10 08 adc %cl,(%rax)
> > > e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi
> > > 1e: 00 51 52 add %dl,0x52(%rcx)
> > > 21: 55 push %rbp
> > > 22: 89 e5 mov %esp,%ebp
> > > 24: 0f 34 sysenter
> > > 26: cd 80 int $0x80
> > > * 28: 5d pop %rbp <-- trapping instruction
> > > 29: 5a pop %rdx
> > > 2a: 59 pop %rcx
> > > 2b: c3 ret
> > > 2c: 90 nop
> > > 2d: 90 nop
> > > 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
> > >
> > >
> > > ---
> > > 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 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
> >
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-02 17:19 ` Aleksandr Nogikh
2025-01-03 19:08 ` Lorenzo Stoakes
@ 2025-01-07 8:14 ` Dmitry Vyukov
2025-01-07 10:15 ` Lorenzo Stoakes
1 sibling, 1 reply; 8+ messages in thread
From: Dmitry Vyukov @ 2025-01-07 8:14 UTC (permalink / raw)
To: Aleksandr Nogikh
Cc: Lorenzo Stoakes, syzbot, Liam.Howlett, akpm, jannh, linux-kernel,
linux-mm, syzkaller-bugs, vbabka
On Thu, 2 Jan 2025 at 18:19, 'Aleksandr Nogikh' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
> On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > Happy new year!
>
> Happy New Year! :)
>
> >
> > On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > userspace arch: i386
> >
> > Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> > userland, 64-bit kernel?
>
> Yes, that's a 32-bit userspace binary running on a 64-bit kernel.
>
> >
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Hmm. Racey thing?
> >
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
> > >
> > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > > </TASK>
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> >
> > It'd be nice if syzbot could actually print the code that generates the
> > warning :) a nice-to-have perhaps.
>
> Thanks for the suggestion!
> I've filed https://github.com/google/syzkaller/issues/5654
It may be better for the kernel to do it. Then it would benefit all
testing systems, and most manual testing/reports as well.
Since WARN_ON is a macro, it should be trivial to capture the
condition string. I guess some embed kernels will want to turn it off,
so probably should be configurable.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [mm?] WARNING in vma_merge_existing_range
2025-01-07 8:14 ` Dmitry Vyukov
@ 2025-01-07 10:15 ` Lorenzo Stoakes
0 siblings, 0 replies; 8+ messages in thread
From: Lorenzo Stoakes @ 2025-01-07 10:15 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Aleksandr Nogikh, syzbot, Liam.Howlett, akpm, jannh,
linux-kernel, linux-mm, syzkaller-bugs, vbabka
On Tue, Jan 07, 2025 at 09:14:54AM +0100, Dmitry Vyukov wrote:
> On Thu, 2 Jan 2025 at 18:19, 'Aleksandr Nogikh' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs
> > <syzkaller-bugs@googlegroups.com> wrote:
> > >
> > > Happy new year!
> >
> > Happy New Year! :)
> >
> > >
> > > On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > > userspace arch: i386
> > >
> > > Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> > > userland, 64-bit kernel?
> >
> > Yes, that's a 32-bit userspace binary running on a 64-bit kernel.
> >
> > >
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > Hmm. Racey thing?
> > >
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+46423ed8fa1f1148c6e4@syzkaller.appspotmail.com
> > > >
> > > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > > > </TASK>
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > >
> > > It'd be nice if syzbot could actually print the code that generates the
> > > warning :) a nice-to-have perhaps.
> >
> > Thanks for the suggestion!
> > I've filed https://github.com/google/syzkaller/issues/5654
>
> It may be better for the kernel to do it. Then it would benefit all
> testing systems, and most manual testing/reports as well.
> Since WARN_ON is a macro, it should be trivial to capture the
> condition string. I guess some embed kernels will want to turn it off,
> so probably should be configurable.
Well, you guys already print the userland portion right? It's not exactly
an area of the kernel I'd like to fiddle with because these splats are
output in unstable conditions and are probably best limited to outputting
minimal information rather than trying to do the computation involved in
disassembly.
I think in any case you've misinterpreted :) so what I'm saying here is
disassembly, you seem to be suggesting the __stringify(cond) thing, which
actually I have now added in this case anyway [0], along with a whole host
of other debug information.
This means next time a non-repro case like this occurs in merge code we'll
have a LOT more to go on.
[0]:https://lore.kernel.org/linux-mm/cover.1735932169.git.lorenzo.stoakes@oracle.com/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-01-07 10:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-01 4:50 [syzbot] [mm?] WARNING in vma_merge_existing_range syzbot
2025-01-02 10:25 ` Lorenzo Stoakes
2025-01-02 11:34 ` Lorenzo Stoakes
2025-01-02 17:19 ` Aleksandr Nogikh
2025-01-03 19:08 ` Lorenzo Stoakes
2025-01-07 8:14 ` Dmitry Vyukov
2025-01-07 10:15 ` Lorenzo Stoakes
2025-01-02 17:31 ` Matthew Wilcox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox