general protection fault in unlink_file_vma

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1166cb5d900000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299
dashboard link: https://syzkaller.appspot.com/bug?extid=c5d5a51dcbb558ca0cb5
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11901e95900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15f56195900000

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1205faed900000
final oops: https://syzkaller.appspot.com/x/report.txt?x=1105faed900000
console output: https://syzkaller.appspot.com/x/log.txt?x=1605faed900000

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

general protection fault, probably for non-canonical address 0xe00eeaee0000003b: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x00777770000001d8-0x00777770000001df]
CPU: 1 PID: 10488 Comm: syz-executor721 Not tainted 5.9.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unlink_file_vma+0x57/0xb0 mm/mmap.c:164
Code: 4c 8b a5 a0 00 00 00 4d 85 e4 74 4e e8 92 d7 cd ff 49 8d bc 24 d8 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 3d 4d 8b b4 24 d8 01 00 00 4d 8d 6e 78 4c 89 ef e8
RSP: 0018:ffffc9000ac0f9b0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88800010ceb0 RCX: ffffffff81592421
RDX: 000eeeee0000003b RSI: ffffffff81a6736e RDI: 00777770000001d8
RBP: ffff88800010ceb0 R08: 0000000000000001 R09: ffff88801291a50f
R10: ffffed10025234a1 R11: 0000000000000001 R12: 0077777000000000
R13: 00007f1eea0da000 R14: 00007f1eea0d9000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1eea11a9d0 CR3: 000000000007e000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
free_pgtables+0x1b3/0x2f0 mm/memory.c:415
exit_mmap+0x2c0/0x530 mm/mmap.c:3184
__mmput+0x122/0x470 kernel/fork.c:1076
mmput+0x53/0x60 kernel/fork.c:1097
exit_mm kernel/exit.c:483 [inline]
do_exit+0xa8b/0x29f0 kernel/exit.c:793
do_group_exit+0x125/0x310 kernel/exit.c:903
get_signal+0x428/0x1f00 kernel/signal.c:2757
arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811
exit_to_user_mode_loop kernel/entry/common.c:136 [inline]
exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:167
syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:242
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446ad9
Code: Bad RIP value.
RSP: 002b:00007f1eea0f8d18 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00000000006dbc58 RCX: 0000000000446ad9
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00000000006dbc58
RBP: 00000000006dbc50 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc5c
R13: 00007f1eea0f8d20 R14: 00007f1eea0f8d20 R15: 20c49ba5e353f7cf
Modules linked in:
---[ end trace 22e4d2773b69c9b0 ]---
RIP: 0010:unlink_file_vma+0x57/0xb0 mm/mmap.c:164
Code: 4c 8b a5 a0 00 00 00 4d 85 e4 74 4e e8 92 d7 cd ff 49 8d bc 24 d8 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 3d 4d 8b b4 24 d8 01 00 00 4d 8d 6e 78 4c 89 ef e8
RSP: 0018:ffffc9000ac0f9b0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88800010ceb0 RCX: ffffffff81592421
RDX: 000eeeee0000003b RSI: ffffffff81a6736e RDI: 00777770000001d8
RBP: ffff88800010ceb0 R08: 0000000000000001 R09: ffff88801291a50f
R10: ffffed10025234a1 R11: 0000000000000001 R12: 0077777000000000
R13: 00007f1eea0da000 R14: 00007f1eea0d9000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1eea11a9d0 CR3: 000000000007e000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Hillf Danton]

Tue, 08 Sep 2020 17:19:17 -0700

Looks like d70cec898324 ("mm: mmap: merge vma after call_mmap() if possible")
added an extra fput.

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1781,7 +1781,6 @@ unsigned long mmap_region(struct file *f
merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
if (merge) {
- fput(file);
vm_area_free(vma);
vma = merge;
/* Update vm_flags and possible addr to pick up the change. We don't

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG at include/linux/mm.h:LINE!

page:00000000dcd63a2e refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x770
flags: 0x7ffe0000000000()
raw: 007ffe0000000000 ffffea000001dc08 ffffea000001dc08 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u <= 127u))
------------[ cut here ]------------
kernel BUG at include/linux/mm.h:1153!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 13921 Comm: syz-executor.5 Not tainted 5.9.0-rc4-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

RIP: 0010:get_page include/linux/mm.h:1153 [inline]
RIP: 0010:copy_one_pte mm/memory.c:805 [inline]
RIP: 0010:copy_pte_range mm/memory.c:854 [inline]
RIP: 0010:copy_pmd_range mm/memory.c:905 [inline]
RIP: 0010:copy_pud_range mm/memory.c:939 [inline]
RIP: 0010:copy_p4d_range mm/memory.c:961 [inline]
RIP: 0010:copy_page_range+0x1b65/0x2810 mm/memory.c:1023
Code: ff e8 ef eb ce ff 0f 0b e8 e8 eb ce ff 0f 0b e8 e1 eb ce ff 0f 0b e8 da eb ce ff 48 c7 c6 20 1c 55 88 4c 89 f7 e8 6b 49 fd ff <0f> 0b e8 c4 eb ce ff 4c 8b b4 24 d8 00 00 00 49 83 ee 01 e9 ee f3
RSP: 0018:ffffc9000d4f7880 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffea000001dc00 RCX: ffffffff81a2bb35
RDX: ffff888079452340 RSI: ffffffff81a2bb84 RDI: ffffea000001dc38
RBP: ffffea000001dc34 R08: 0000000000000059 R09: ffff8880ae720f8b
R10: ffffffffffffffff R11: 0000000000000001 R12: 0000000000770055
R13: dffffc0000000000 R14: ffffea000001dc00 R15: 0000000000000015
FS: 00007f039c88f700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007f039c88edb8 CR3: 00000000531c2000 CR4: 00000000001506e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:

dup_mmap kernel/fork.c:592 [inline]
dup_mm+0x98f/0x1300 kernel/fork.c:1354
copy_mm kernel/fork.c:1410 [inline]
copy_process+0x28e4/0x6920 kernel/fork.c:2069
_do_fork+0xe8/0xb10 kernel/fork.c:2428
__do_sys_clone+0xc8/0x110 kernel/fork.c:2545
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45d5b9
Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f039c88ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 0000000000001f40 RCX: 000000000045d5b9
RDX: 9999999999999999 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 000000000118d0d0 R08: ffffffffffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118d08c
R13: 00007ffec024adbf R14: 00007f039c88f9c0 R15: 000000000118d08c
Modules linked in:
---[ end trace 66ee6cc1fdef66b5 ]---
RIP: 0010:get_page include/linux/mm.h:1153 [inline]
RIP: 0010:copy_one_pte mm/memory.c:805 [inline]
RIP: 0010:copy_pte_range mm/memory.c:854 [inline]
RIP: 0010:copy_pmd_range mm/memory.c:905 [inline]
RIP: 0010:copy_pud_range mm/memory.c:939 [inline]
RIP: 0010:copy_p4d_range mm/memory.c:961 [inline]
RIP: 0010:copy_page_range+0x1b65/0x2810 mm/memory.c:1023
Code: ff e8 ef eb ce ff 0f 0b e8 e8 eb ce ff 0f 0b e8 e1 eb ce ff 0f 0b e8 da eb ce ff 48 c7 c6 20 1c 55 88 4c 89 f7 e8 6b 49 fd ff <0f> 0b e8 c4 eb ce ff 4c 8b b4 24 d8 00 00 00 49 83 ee 01 e9 ee f3
RSP: 0018:ffffc9000d4f7880 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffea000001dc00 RCX: ffffffff81a2bb35
RDX: ffff888079452340 RSI: ffffffff81a2bb84 RDI: ffffea000001dc38
RBP: ffffea000001dc34 R08: 0000000000000059 R09: ffff8880ae720f8b
R10: ffffffffffffffff R11: 0000000000000001 R12: 0000000000770055
R13: dffffc0000000000 R14: ffffea000001dc00 R15: 0000000000000015
FS: 00007f039c88f700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007f039c88edb8 CR3: 00000000531c2000 CR4: 00000000001506e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Tested on:

commit: 34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14ab7263900000
kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9

[Souptick Joarder]

Hi Hiff,

Can you please help me to understand how do you figure out this commit ?

[Hillf Danton]

On Thu, 10 Sep 2020 07:43:41 +0530 Souptick Joarder wrote:

Feel free to correct Hillf if I missed any thing.
Failing to reproduce the gpf without the commit may tell us more about it
than I could.

[linmiaohe]

Hillf Danton wrote:
>> On Thu, 10 Sep 2020 07:43:41 +0530 Souptick Joarder wrote:
>> On Wed, Sep 9, 2020 at 9:45 AM Hillf Danton wrote:
>> > Tue, 08 Sep 2020 17:19:17 -0700
>> > > syzbot found the following issue on:
>> > >
>> > > HEAD commit: 59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..
>> >

>> > Looks like d70cec898324 ("mm: mmap: merge vma after call_mmap() if
>> > possible") added an extra fput.
>>
>> Can you please help me to understand how do you figure out this commit ?
>
>Feel free to correct Hillf if I missed any thing.
>Failing to reproduce the gpf without the commit may tell us more about it than I could.
>> >
>> > --- a/mm/mmap.c
>> > +++ b/mm/mmap.c
>> > @@ -1781,7 +1781,6 @@ unsigned long mmap_region(struct file *f
>> > merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
>> > NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
>> > if (merge) {
>> > - fput(file);
>> > vm_area_free(vma);
>> > vma = merge;
>> > /* Update vm_flags and possible addr
>> > to pick up the change. We don't

Yes, It seems vma_merge() could fput the vm_file via remove_next case in __vma_adjust(). So the fput vm_file here do the
extra one.

But we may not remove the fput here directly as vma_merge() do not always fput the vm_file. I'am not really familiar with
the vma merge yet, but I would try my best to fix this as soon as possible.

Many thanks for point this out. And sorry for my careless.

[linmiaohe]

Hi:

Hillf Danton <hda...@sina.com> wrote:
> Tue, 08 Sep 2020 17:19:17 -0700
>> syzbot found the following issue on:

>> general protection fault, probably for non-canonical address
>> 0xe00eeaee0000003b: 0000 [#1] PREEMPT SMP KASAN
>> KASAN: maybe wild-memory-access in range
>> [0x00777770000001d8-0x00777770000001df]

...
>> entry_SYSCALL_64_after_hwframe+0x44/0xa9

>
>Looks like d70cec898324 ("mm: mmap: merge vma after call_mmap() if possible") added an extra fput.
>

>--- a/mm/mmap.c
>+++ b/mm/mmap.c
>@@ -1781,7 +1781,6 @@ unsigned long mmap_region(struct file *f
> merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
> NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
> if (merge) {
>- fput(file);
> vm_area_free(vma);
> vma = merge;
> /* Update vm_flags and possible addr to pick up the change. We don't
>

I reviewed the code carefully these days and I found vma_merge() do only fput() the vm_file of the linked vma in remove_next cases.
This gpf is much likely because the ->mmap() callback can change vma->vm_file and fput the original file. But my previous commit
failed to catch this case and always fput() the original file, hence add an extra fput().
The below patch would make the things right:

diff --git a/mm/mmap.c b/mm/mmap.c
index 080f44bcf7a8..80ea11bf12fa 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1816,7 +1816,11 @@ unsigned long mmap_region(struct file *file, unsigned long addr,

merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
if (merge) {
- fput(file);

+ /* ->mmap() can change vma->vm_file and fput the original file. So
+ * fput the vma->vm_file here or we would add an extra fput for file
+ * and cause general protection fault ultimately.
+ */
+ fput(vma->vm_file);

vm_area_free(vma);
vma = merge;
/* Update vm_flags and possible addr to pick up the change. We don't

It's very nice of you if you could help test this patch as I can't reproduce it in my product environment. And many thanks
for a possible Tested-by tag.

Thanks again.

[Hillf Danton]

On Sun, 13 Sep 2020 09:17:26 +0000 linmiaohe wrote:
>
> I reviewed the code carefully these days and I found vma_merge() do only fput() the vm_file of the linked vma in remove_next cases.
> This gpf is much likely because the ->mmap() callback can change vma->vm_file and fput the original file. But my previous commit
> failed to catch this case and always fput() the original file, hence add an extra fput().
> The below patch would make the things right:
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 080f44bcf7a8..80ea11bf12fa 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1816,7 +1816,11 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
> NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
> if (merge) {
> - fput(file);
> + /* ->mmap() can change vma->vm_file and fput the original file. So
> + * fput the vma->vm_file here or we would add an extra fput for file
> + * and cause general protection fault ultimately.
> + */
> + fput(vma->vm_file);
> vm_area_free(vma);
> vma = merge;
> /* Update vm_flags and possible addr to pick up the change. We don't
>
> It's very nice of you if you could help test this patch as I can't reproduce it in my product environment. And many thanks
> for a possible Tested-by tag.

Take another look at the Cc list and the link below.

https://lore.kernel.org/lkml/20200911120...@ziepe.ca/

[linmiaohe]

Hillf Danton <hda...@sina.com> wrote:
> On Sun, 13 Sep 2020 09:17:26 +0000 linmiaohe wrote:
>>
>> I reviewed the code carefully these days and I found vma_merge() do only fput() the vm_file of the linked vma in remove_next cases.
>> This gpf is much likely because the ->mmap() callback can change
>> vma->vm_file and fput the original file. But my previous commit failed to catch this case and always fput() the original file, hence add an extra fput().
>> The below patch would make the things right:
>>
>

>Take another look at the Cc list and the link below.
>
>https://lore.kernel.org/lkml/20200911120...@ziepe.ca/
>

Many thanks for your teach. I think I could send the proposed patch to the syzbot directly.
Thanks again.:)

[linmiaohe]

Tue, 08 Sep 2020 17:19:17 -0700
> syzbot found the following issue on:
>

> HEAD commit: 59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..

> git tree: upstream
> console output:
> https://syzkaller.appspot.com/x/log.txt?x=1166cb5d900000
> kernel config:
> https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299
> dashboard link: https://syzkaller.appspot.com/bug?extid=c5d5a51dcbb558ca0cb5
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11901e95900000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15f56195900000
>
> Bisection is inconclusive: the issue happens on the oldest tested release.
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1205faed900000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1105faed900000
> console output:
> https://syzkaller.appspot.com/x/log.txt?x=1605faed900000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c5d5a5...@syzkaller.appspotmail.com
>

> general protection fault, probably for non-canonical address
> 0xe00eeaee0000003b: 0000 [#1] PREEMPT SMP KASAN
> KASAN: maybe wild-memory-access in range
> [0x00777770000001d8-0x00777770000001df]

#syz test: https://github.com/Linmiaohe/linux/ 796cd8f497d5b62b00667229375326381c32bdb3

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:

kernel panic: corrupted stack end in sys_nanosleep

Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 0 PID: 13791 Comm: syz-executor.4 Not tainted 5.9.0-rc5-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x198/0x1fd lib/dump_stack.c:118
panic+0x347/0x7c0 kernel/panic.c:231
schedule_debug kernel/sched/core.c:4278 [inline]
__schedule+0x221e/0x2230 kernel/sched/core.c:4422
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
freezable_schedule include/linux/freezer.h:172 [inline]
do_nanosleep+0x222/0x650 kernel/time/hrtimer.c:1883
hrtimer_nanosleep+0x1f9/0x430 kernel/time/hrtimer.c:1936
__do_sys_nanosleep kernel/time/hrtimer.c:1970 [inline]
__se_sys_nanosleep kernel/time/hrtimer.c:1957 [inline]
__x64_sys_nanosleep+0x1dc/0x260 kernel/time/hrtimer.c:1957
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ba81
Code: 75 14 b8 23 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 84 cf fb ff c3 48 83 ec 08 e8 ea 46 00 00 48 89 04 24 b8 23 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 33 47 00 00 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007ffca6cb6d70 EFLAGS: 00000293 ORIG_RAX: 0000000000000023
RAX: ffffffffffffffda RBX: 000000000002f226 RCX: 000000000045ba81
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffca6cb6d80
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 00007ffca6cb6e80 R11: 0000000000000293 R12: 000000000118cf40
R13: 000000000118d940 R14: ffffffffffffffff R15: 000000000118cfec
Kernel Offset: disabled
Rebooting in 86400 seconds..


Tested on:

commit: 796cd8f4 fix gpf
git tree: https://github.com/Linmiaohe/linux/
console output: https://syzkaller.appspot.com/x/log.txt?x=12b5d501900000
kernel config: https://syzkaller.appspot.com/x/.config?x=f82e58a6661a5ac4

[linmiaohe]

This issue looks like irrelevant with my previous commit, maybe it's because I fix this on wrong commit.
I would rebase this on commit 59126901 ("Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..").
Thanks.

[linmiaohe]

#syz test: https://github.com/Linmiaohe/linux vma_merge_fix

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:

kernel panic: Fatal exception

RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000

R10: 00007ffd30630720 R11: 0000000000000000 R12: 000000000118d940

R13: 000000000118d940 R14: ffffffffffffffff R15: 000000000118cfec

FS: 0000000001b47940(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0033 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001590004 CR3: 0000000021097000 CR4: 00000000001506e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled


Tested on:

commit: 8f79400b fix vma_merge gpf
git tree: https://github.com/Linmiaohe/linux vma_merge_fix
console output: https://syzkaller.appspot.com/x/log.txt?x=153b1d43900000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299

[linmiaohe]

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:

kernel BUG at arch/x86/mm/physaddr.c:LINE!

------------[ cut here ]------------
kernel BUG at arch/x86/mm/physaddr.c:28!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 6975 Comm: syz-executor.2 Not tainted 5.9.0-rc3-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

RIP: 0010:__phys_addr+0xa7/0x110 arch/x86/mm/physaddr.c:28
Code: 92 7d 09 4c 89 e3 31 ff 48 d3 eb 48 89 de e8 10 8e 3f 00 48 85 db 75 0d e8 66 91 3f 00 4c 89 e0 5b 5d 41 5c c3 e8 59 91 3f 00 <0f> 0b e8 52 91 3f 00 48 c7 c0 10 50 a9 89 48 ba 00 00 00 00 00 fc
RSP: 0018:ffffc900055e7a18 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000007700000000 RCX: ffffffff8134b948
RDX: ffff8880a83c8280 RSI: ffffffff8134b9a7 RDI: 0000000000000006
RBP: 0000007780000000 R08: 0000000000000001 R09: ffffffff8c5f4a57
R10: 0000007780000000 R11: 0000000000000000 R12: 000077f700000000
R13: ffffc900055e7a80 R14: 0000000000000200 R15: dffffc0000000000
FS: 000000000221c940(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000749198 CR3: 00000000a7df1000 CR4: 00000000001506f0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Call Trace:
virt_to_head_page include/linux/mm.h:848 [inline]
qlink_to_cache mm/kasan/quarantine.c:128 [inline]
qlist_free_all+0xd9/0x170 mm/kasan/quarantine.c:165
quarantine_reduce+0x17e/0x200 mm/kasan/quarantine.c:261
__kasan_kmalloc.constprop.0+0x9e/0xd0 mm/kasan/common.c:442
slab_post_alloc_hook mm/slab.h:518 [inline]
slab_alloc_node mm/slab.c:3254 [inline]
kmem_cache_alloc_node_trace+0x144/0x3f0 mm/slab.c:3592
kmalloc_node include/linux/slab.h:572 [inline]
kzalloc_node include/linux/slab.h:677 [inline]
__get_vm_area_node+0x126/0x3b0 mm/vmalloc.c:2075
__vmalloc_node_range mm/vmalloc.c:2506 [inline]
__vmalloc_node mm/vmalloc.c:2554 [inline]
vzalloc+0xf2/0x1a0 mm/vmalloc.c:2607
do_ipt_get_ctl+0x613/0x9d0 net/ipv4/netfilter/ip_tables.c:800
nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
ip_getsockopt net/ipv4/ip_sockglue.c:1778 [inline]
ip_getsockopt+0x164/0x1c0 net/ipv4/ip_sockglue.c:1757
tcp_getsockopt+0x86/0xd0 net/ipv4/tcp.c:3876
__sys_getsockopt+0x219/0x4c0 net/socket.c:2173
__do_sys_getsockopt net/socket.c:2188 [inline]
__se_sys_getsockopt net/socket.c:2185 [inline]
__x64_sys_getsockopt+0xba/0x150 net/socket.c:2185
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4600ca
Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 3d 89 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 1a 89 fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007fff61ca7778 EFLAGS: 00000216 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 00007fff61ca77a0 RCX: 00000000004600ca
RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000749e60 R08: 00007fff61ca779c R09: 0000000000004000
R10: 00007fff61ca7800 R11: 0000000000000216 R12: 00007fff61ca7800
R13: 0000000000000003 R14: 00000000007497a0 R15: 0000000000000000
Modules linked in:
---[ end trace 58c08b00b19487d8 ]---
RIP: 0010:__phys_addr+0xa7/0x110 arch/x86/mm/physaddr.c:28
Code: 92 7d 09 4c 89 e3 31 ff 48 d3 eb 48 89 de e8 10 8e 3f 00 48 85 db 75 0d e8 66 91 3f 00 4c 89 e0 5b 5d 41 5c c3 e8 59 91 3f 00 <0f> 0b e8 52 91 3f 00 48 c7 c0 10 50 a9 89 48 ba 00 00 00 00 00 fc
RSP: 0018:ffffc900055e7a18 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000007700000000 RCX: ffffffff8134b948
RDX: ffff8880a83c8280 RSI: ffffffff8134b9a7 RDI: 0000000000000006
RBP: 0000007780000000 R08: 0000000000000001 R09: ffffffff8c5f4a57
R10: 0000007780000000 R11: 0000000000000000 R12: 000077f700000000
R13: ffffc900055e7a80 R14: 0000000000000200 R15: dffffc0000000000
FS: 000000000221c940(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000749198 CR3: 00000000a7df1000 CR4: 00000000001506f0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Tested on:

commit: 152d246f mmap: revert mm-mmap-merge-vma-after-call_mmap-if..

git tree: https://github.com/Linmiaohe/linux vma_merge_fix

console output: https://syzkaller.appspot.com/x/log.txt?x=162e6cc5900000

[linmiaohe]

I revert my previous commit altogether, d70cec8983241a ("mm: mmap: merge vma after call_mmap() if possible "), but there is still irrelevant issue.
And with my previous commit and proposed patch, the origin general protection fault in unlink_file_vma disappeared.
So I think this is another issue and the origin issue is fixed with my patch.
Thanks.