lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 25 Jan 2021 11:26:09 +0800
From:   Li Xinhai <lixinhai.lxh@...il.com>
To:     syzbot <syzbot+9b83ff893245a25c320e@...kaller.appspotmail.com>,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, sfr@...b.auug.org.au,
        syzkaller-bugs@...glegroups.com
Subject: Re: kernel BUG in split_huge_page_to_list



On 1/24/21 8:01 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    647060f3 Add linux-next specific files for 20210120
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16f0353f500000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8f8a72b7e5067002
> dashboard link: https://syzkaller.appspot.com/bug?extid=9b83ff893245a25c320e
> compiler:       gcc (GCC) 10.1.0-syz 20200507
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=143d7e3b500000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17652feb500000
> 

It looks like a new page been mapped by the old vma, which happen
- after the existing page table entry moved from old vma to new vma;
- before unlinking anon_vma from old vma;

So this new page's ->mapping still points to the anon_vma which been
unlinked by the old vma. later, rmap path would not be able to find
mapped entries of this page.

Any hints about above scenario? I suppose it only possible for THP
pages and not happen through page fault path. Thanks.


> The issue was bisected to:
> 
> commit fbdbae3da30a149a55a5f1883bbbe17a27660e05
> Author: Li Xinhai <lixinhai.lxh@...il.com>
> Date:   Tue Jan 19 21:54:00 2021 +0000
> 
>      mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16cad100d00000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=15cad100d00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=11cad100d00000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+9b83ff893245a25c320e@...kaller.appspotmail.com
> Fixes: fbdbae3da30a ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success")
> 
> head:00000000091c6650 order:9 compound_mapcount:0 compound_pincount:0
> memcg:ffff888010d0a000
> anon flags: 0xfff0000009001d(locked|uptodate|dirty|lru|head|swapbacked)
> raw: 00fff0000009001d ffffea0000bc51c8 ffff888010201800 ffff88802575d801
> raw: 0000000000020e00 0000000000000000 000001fc00000000 ffff888010d0a000
> page dumped because: VM_BUG_ON_PAGE(!unmap_success)
> ------------[ cut here ]------------
> kernel BUG at mm/huge_memory.c:2351!
> invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 8483 Comm: syz-executor525 Not tainted 5.11.0-rc4-next-20210120-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:unmap_page mm/huge_memory.c:2351 [inline]
> RIP: 0010:split_huge_page_to_list+0x1f02/0x43b0 mm/huge_memory.c:2720
> Code: ef e8 82 46 ea ff 0f 0b e8 ab 69 b9 ff 4c 8d 73 ff e9 56 ea ff ff e8 9d 69 b9 ff 48 c7 c6 40 69 57 89 48 89 ef e8 5e 46 ea ff <0f> 0b e8 87 69 b9 ff 4c 8d 75 ff e9 28 e9 ff ff e8 79 69 b9 ff 49
> RSP: 0018:ffffc9000168f7a0 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff88801e2d5400 RSI: ffffffff88bcc6c7 RDI: fffff520002d1e8e
> RBP: ffffea0000ca8000 R08: 0000000000000033 R09: 0000000000000000
> R10: ffffffff815b136e R11: 0000000000000000 R12: ffff888010d0ae60
> R13: ffffea0000ca8000 R14: 000000000000018c R15: 0000000000000000
> FS:  000000000154e880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fcc655666c0 CR3: 0000000012e9a000 CR4: 00000000001506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   split_huge_page include/linux/huge_mm.h:187 [inline]
>   madvise_free_pte_range+0x736/0x1ee0 mm/madvise.c:633
>   walk_pmd_range mm/pagewalk.c:89 [inline]
>   walk_pud_range mm/pagewalk.c:160 [inline]
>   walk_p4d_range mm/pagewalk.c:193 [inline]
>   walk_pgd_range mm/pagewalk.c:229 [inline]
>   __walk_page_range+0xe20/0x1ea0 mm/pagewalk.c:331
>   walk_page_range+0x20d/0x400 mm/pagewalk.c:427
>   madvise_free_single_vma+0x383/0x550 mm/madvise.c:731
>   madvise_dontneed_free mm/madvise.c:819 [inline]
>   madvise_vma mm/madvise.c:936 [inline]
>   do_madvise.part.0+0x4e4/0x1ed0 mm/madvise.c:1132
>   do_madvise mm/madvise.c:1158 [inline]
>   __do_sys_madvise mm/madvise.c:1158 [inline]
>   __se_sys_madvise mm/madvise.c:1156 [inline]
>   __x64_sys_madvise+0x113/0x150 mm/madvise.c:1156
>   do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x440219
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffc51b58b98 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440219
> RDX: 0000000000000008 RSI: 0000000000c00000 RDI: 0000000020400000
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000020ffc000 R11: 0000000000000246 R12: 0000000000401a20
> R13: 0000000000401ab0 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in:
> ---[ end trace 7812a13de61fd12e ]---
> RIP: 0010:unmap_page mm/huge_memory.c:2351 [inline]
> RIP: 0010:split_huge_page_to_list+0x1f02/0x43b0 mm/huge_memory.c:2720
> Code: ef e8 82 46 ea ff 0f 0b e8 ab 69 b9 ff 4c 8d 73 ff e9 56 ea ff ff e8 9d 69 b9 ff 48 c7 c6 40 69 57 89 48 89 ef e8 5e 46 ea ff <0f> 0b e8 87 69 b9 ff 4c 8d 75 ff e9 28 e9 ff ff e8 79 69 b9 ff 49
> RSP: 0018:ffffc9000168f7a0 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff88801e2d5400 RSI: ffffffff88bcc6c7 RDI: fffff520002d1e8e
> RBP: ffffea0000ca8000 R08: 0000000000000033 R09: 0000000000000000
> R10: ffffffff815b136e R11: 0000000000000000 R12: ffff888010d0ae60
> R13: ffffea0000ca8000 R14: 000000000000018c R15: 0000000000000000
> FS:  000000000154e880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fcc655666c0 CR3: 0000000012e9a000 CR4: 00000000001506f0
> 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 syzkaller@...glegroups.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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ