linux-kernel - Re: [PATCH 4.18 000/123] 4.18.6-stable review

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]

Date:   Tue, 4 Sep 2018 10:12:13 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     holger@...lied-asynchrony.com
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Shuah Khan <shuah@...nel.org>, patches@...nelci.org,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        lkft-triage@...ts.linaro.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.18 000/123] 4.18.6-stable review

On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
<holger@...lied-asynchrony.com> wrote:
>
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep  3 20:19:38 ragnarok kernel:  tlb_table_flush.part.13+0xe/0x30
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep  3 20:19:38 ragnarok kernel:  tlb_table_flush.part.13+0xe/0x30
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x54/0xc0
> Sep  3 20:19:38 ragnarok kernel:  arch_tlb_finish_mmu+0x3a/0x70
> Sep  3 20:19:38 ragnarok kernel:  tlb_finish_mmu+0x1f/0x30

Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
stable tree (because it wasn't an obvious dependency).

And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
which in turn calls tlb_table_invalidate(), which calls back to
tlb_flush_mmu_tlbonly().

So you have endless recursion - at least until you run out of stack.
Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
nice clean kernel stack overflow message like you did.

Or if you have KASAN enabled and no VMAP stack, you just end up with
random hangs and huge memory corruption as the recursion stomps all
over your memory.

          Linus