linux-kernel - Re: Linux 5.0 regression: BUG: unable to handle kernel paging request at ffff888023e26778

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=winXFRv0KUa332spZx0yaDKMAbdKSeAcBATtacACLgm0A@mail.gmail.com>
Date:   Sat, 9 Feb 2019 10:54:27 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Sander Eikelenboom <linux@...elenboom.it>
Cc:     Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: Linux 5.0 regression: BUG: unable to handle kernel paging request
 at ffff888023e26778

On Sat, Feb 9, 2019 at 12:24 AM Sander Eikelenboom <linux@...elenboom.it> wrote:
>
> I haven't got a reproducer so i might be hard to hit it again,
> system is AMD and this is from the host kernel running under
> the Xen hypervisor might it matter.

I think this is a Xen bug.

In particular, there's a few poison values in there that look like
zen. Like this:

   R10: deadbeefdeadf00d

looks like a special poison value that is from Xen itself.

It looks like the oops is around the TLB flushing code, looking at the
code it's the

        arch_leave_lazy_mmu_mode();
        if (force_flush)
                flush_tlb_range(vma, old_end - len, old_end);
        if (new_ptl != old_ptl)
                spin_unlock(new_ptl);

sequence in move_page_tables. The oopsing code sequence is


  28:* 48 89 45 00          mov    %rax,0x0(%rbp) <-- trapping instruction
  2c: 41 f6 46 52 40        testb  $0x40,0x52(%r14)

and that "testb $0x40" instruction that comes after the trapping
instruction is the

                           ((vma)->vm_flags & VM_HUGETLB)               \

from the flush_tlb_range() macro:

#define flush_tlb_range(vma, start, end)                                \
        flush_tlb_mm_range((vma)->vm_mm, start, end,                    \
                           ((vma)->vm_flags & VM_HUGETLB)               \
                                ? huge_page_shift(hstate_vma(vma))      \
                                : PAGE_SHIFT, false)

if I read that oops correctly.

I have no idea what that store to 0(%rbp) is for, though - I can't
line that up with anything I see with my own kernel config.

We *do* have changes to 5.0 in the move_page_tables() code (mremap on
a pmd level), so I'm cc'ing some of the people involved there, but
that odd poison value does make me wonder abut Xen issues. When I
google for that value, all I see is Xen reports (and your report for
this).

                    Linus