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]
Message-ID: <CACT4Y+aLQ_wYBvcnevLXGUy9WBgrdpV43vhwTKgwmNrEfRTf6A@mail.gmail.com>
Date:   Wed, 2 Jan 2019 11:32:08 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     syzbot <syzbot+a5fea9200aefd1cf4818@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Hugh Dickins <hughd@...gle.com>,
        Jerome Glisse <jglisse@...hat.com>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, Michal Hocko <mhocko@...e.com>,
        David Rientjes <rientjes@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: general protection fault in transparent_hugepage_enabled

On Wed, Jan 2, 2019 at 11:24 AM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> On 1/2/19 11:03 AM, Dmitry Vyukov wrote:
> > On Wed, Jan 2, 2019 at 10:47 AM Vlastimil Babka <vbabka@...e.cz> wrote:
> >>
> >> Actually the fix was folded into the patch that caused the bug, and was
> >> already sent to and merged by Linus, commit
> >> 7635d9cbe8327e131a1d3d8517dc186c2796ce2e
> >
> >
> > But the email thread you referenced says that we need:
> >
> > @@ -66,6 +66,8 @@ bool transparent_hugepage_enabled(struct vm_area_struct *vma)
> >  {
> >   if (vma_is_anonymous(vma))
> >   return __transparent_hugepage_enabled(vma);
> > + if (!vma->vm_file || !vma->vm_file->f_mapping)
> > + return false;
> >   if (shmem_mapping(vma->vm_file->f_mapping) && shmem_huge_enabled(vma))
> >   return __transparent_hugepage_enabled(vma);
> >
> > and 7635d9cbe8327e131a1d3d8517dc186c2796ce2e contains:
> >
> > +bool transparent_hugepage_enabled(struct vm_area_struct *vma)
> > +{
> > +       if (vma_is_anonymous(vma))
> > +               return __transparent_hugepage_enabled(vma);
> > +       if (vma_is_shmem(vma) && shmem_huge_enabled(vma))
> > +               return __transparent_hugepage_enabled(vma);
> > +
> > +       return false;
> > +}
> >
> > What am I missing?
>
> Ah, the solution with vma_is_shmem() appeared later in the thread:
> https://marc.info/?l=linux-mm&m=154567747315893&w=2

Ah, thanks, just wanted to make sure I understand what happens here.
Then let's record this in trackable way:

#syz fix: mm, thp, proc: report THP eligibility for each vma

> >>>>> Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00
> >>>>> 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> >>>>> 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6
> >>>>> RSP: 0018:ffff8881c2237138 EFLAGS: 00010202
> >>>>> RAX: dffffc0000000000 RBX: ffff8881c2bdbc60 RCX: 0000000000000000
> >>>>> RDX: 0000000000000037 RSI: ffffffff81c8fa1a RDI: 00000000000001b8
> >>>>> RBP: ffff8881c2237160 R08: ffffed10383b25ed R09: ffffed10383b25ec
> >>>>> R10: ffffed10383b25ec R11: ffff8881c1d92f63 R12: 0000000000000000
> >>>>> R13: ffff8881c2bdbd00 R14: dffffc0000000000 R15: 0000000000000f5e
> >>>>> FS:  0000000001a48880(0000) GS:ffff8881dad00000(0000) knlGS:0000000000000000
> >>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>>>> CR2: 0000000020b58000 CR3: 00000001c2210000 CR4: 00000000001406e0
> >>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >>>>> Call Trace:
> >>>>>   show_smap+0x167/0x580 fs/proc/task_mmu.c:805
> >>>>>   traverse+0x344/0x7b0 fs/seq_file.c:113
> >>>>>   seq_read+0xc76/0x1150 fs/seq_file.c:188
> >>>>>   do_loop_readv_writev fs/read_write.c:700 [inline]
> >>>>>   do_iter_read+0x4bc/0x670 fs/read_write.c:924
> >>>>>   vfs_readv+0x175/0x1c0 fs/read_write.c:986
> >>>>>   kernel_readv fs/splice.c:362 [inline]
> >>>>>   default_file_splice_read+0x539/0xb20 fs/splice.c:417
> >>>>>   do_splice_to+0x12e/0x190 fs/splice.c:880
> >>>>>   splice_direct_to_actor+0x31c/0x9d0 fs/splice.c:957
> >>>>>   do_splice_direct+0x2d4/0x420 fs/splice.c:1066
> >>>>>   do_sendfile+0x62a/0xe50 fs/read_write.c:1439
> >>>>>   __do_sys_sendfile64 fs/read_write.c:1494 [inline]
> >>>>>   __se_sys_sendfile64 fs/read_write.c:1486 [inline]
> >>>>>   __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1486
> >>>>>   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> >>>>>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >>>>> RIP: 0033:0x440089
> >>>>> 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 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> >>>>> RSP: 002b:00007fff3d710a18 EFLAGS: 00000213 ORIG_RAX: 0000000000000028
> >>>>> RAX: ffffffffffffffda RBX: 00007fff3d710a20 RCX: 0000000000440089
> >>>>> RDX: 0000000020b58000 RSI: 0000000000000003 RDI: 0000000000000003
> >>>>> RBP: 00000000006ca018 R08: 0000000000000010 R09: 65732f636f72702f
> >>>>> R10: 000000000000ffff R11: 0000000000000213 R12: 0000000000401970
> >>>>> R13: 0000000000401a00 R14: 0000000000000000 R15: 0000000000000000
> >>>>> Modules linked in:
> >>>>> ---[ end trace faf026efd8795e93 ]---
> >>>>> RIP: 0010:transparent_hugepage_enabled+0x8c/0x5e0 mm/huge_memory.c:69
> >>>>> Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00
> >>>>> 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> >>>>> 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6
> >>>>> RSP: 0018:ffff8881c2237138 EFLAGS: 00010202
> >>>>> RAX: dffffc0000000000 RBX: ffff8881c2bdbc60 RCX: 0000000000000000
> >>>>> RDX: 0000000000000037 RSI: ffffffff81c8fa1a RDI: 00000000000001b8
> >>>>> RBP: ffff8881c2237160 R08: ffffed10383b25ed R09: ffffed10383b25ec
> >>>>> R10: ffffed10383b25ec R11: ffff8881c1d92f63 R12: 0000000000000000
> >>>>> R13: ffff8881c2bdbd00 R14: dffffc0000000000 R15: 0000000000000f5e
> >>>>> FS:  0000000001a48880(0000) GS:ffff8881dad00000(0000) knlGS:0000000000000000
> >>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>>>> CR2: 0000000020b58000 CR3: 00000001c2210000 CR4: 00000000001406e0
> >>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >>>>>
> >>>>>
> >>>>> ---
> >>>>> This bug 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 bug report. See:
> >>>>> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> >>>>> syzbot.
> >>>>> syzbot can test patches for this bug, for details see:
> >>>>> https://goo.gl/tpsmEJ#testing-patches
> >>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ