linux-kernel - Re: [PATCH RT] Revert "ARM: Initialize split page table locks for vector page"

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: <20191015162609.GH32665@bombadil.infradead.org>
Date:   Tue, 15 Oct 2019 09:26:09 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Frank Rowand <frank.rowand@...sony.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH RT] Revert "ARM: Initialize split page table locks for
 vector page"

On Mon, Oct 14, 2019 at 06:02:38PM +0200, Sebastian Andrzej Siewior wrote:
> I'm dropping this patch, with its original description:
> 
> |ARM: Initialize split page table locks for vector page
> |
> |Without this patch, ARM can not use SPLIT_PTLOCK_CPUS if
> |PREEMPT_RT_FULL=y because vectors_user_mapping() creates a
> |VM_ALWAYSDUMP mapping of the vector page (address 0xffff0000), but no
> |ptl->lock has been allocated for the page.  An attempt to coredump
> |that page will result in a kernel NULL pointer dereference when
> |follow_page() attempts to lock the page.
> |
> |The call tree to the NULL pointer dereference is:
> |
> |   do_notify_resume()
> |      get_signal_to_deliver()
> |         do_coredump()
> |            elf_core_dump()
> |               get_dump_page()
> |                  __get_user_pages()
> |                     follow_page()
> |                        pte_offset_map_lock() <----- a #define
> |                           ...
> |                              rt_spin_lock()
> |
> |The underlying problem is exposed by mm-shrink-the-page-frame-to-rt-size.patch.
> 
> The patch named mm-shrink-the-page-frame-to-rt-size.patch was dropped
> from the RT queue once the SPLIT_PTLOCK_CPUS feature (in a slightly
> different shape) went upstream (somewhere between v3.12 and v3.14).
> 
> I can see that the patch still allocates a lock which wasn't there
> before. However I can't trigger a kernel oops like described in the
> patch by triggering a coredump.

Did your test build have ALLOC_SPLIT_PTLOCKS defined?