linux-kernel - Re: [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to sync top level kernel page tables

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: <20250725165101.e636bbe3fa69ad0b73810914@linux-foundation.org>
Date: Fri, 25 Jul 2025 16:51:01 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 "H . Peter Anvin" <hpa@...cr.com>, Andrey Ryabinin
 <ryabinin.a.a@...il.com>, Arnd Bergmann <arnd@...db.de>, Dennis Zhou
 <dennis@...nel.org>, Tejun Heo <tj@...nel.org>, Christoph Lameter
 <cl@...two.org>, Alexander Potapenko <glider@...gle.com>, Andrey Konovalov
 <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo
 Frascino <vincenzo.frascino@....com>, Juergen Gross <jgross@...e.de>, Kevin
 Brodsky <kevin.brodsky@....com>, Oscar Salvador <osalvador@...e.de>, Joao
 Martins <joao.m.martins@...cle.com>, Lorenzo Sccakes
 <lorenzo.stoakes@...cle.com>, Jane Chu <jane.chu@...cle.com>, Alistair
 Popple <apopple@...dia.com>, Mike Rapoport <rppt@...nel.org>, David
 Hildenbrand <david@...hat.com>, Gwan-gyeong Mun
 <gwan-gyeong.mun@...el.com>, "Aneesh Kumar K . V"
 <aneesh.kumar@...ux.ibm.com>, Uladzislau Rezki <urezki@...il.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka
 <vbabka@...e.cz>, Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko
 <mhocko@...e.com>, Qi Zheng <zhengqi.arch@...edance.com>, Ard Biesheuvel
 <ardb@...nel.org>, Thomas Huth <thuth@...hat.com>, John Hubbard
 <jhubbard@...dia.com>, Ryan Roberts <ryan.roberts@....com>, Peter Xu
 <peterx@...hat.com>, Dev Jain <dev.jain@....com>, Bibo Mao
 <maobibo@...ngson.cn>, Anshuman Khandual <anshuman.khandual@....com>, Joerg
 Roedel <joro@...tes.org>, x86@...nel.org, linux-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to
 sync top level kernel page tables

On Fri, 25 Jul 2025 10:21:01 +0900 Harry Yoo <harry.yoo@...cle.com> wrote:

> During our internal testing, we started observing intermittent boot
> failures when the machine uses 4-level paging and has a large amount
> of persistent memory:
> 
>   BUG: unable to handle page fault for address: ffffe70000000034
>   #PF: supervisor write access in kernel mode
>   #PF: error_code(0x0002) - not-present page
>   PGD 0 P4D 0 
>   Oops: 0002 [#1] SMP NOPTI
>   RIP: 0010:__init_single_page+0x9/0x6d
>   Call Trace:
>    <TASK>
>    __init_zone_device_page+0x17/0x5d
>    memmap_init_zone_device+0x154/0x1bb
>    pagemap_range+0x2e0/0x40f
>    memremap_pages+0x10b/0x2f0
>    devm_memremap_pages+0x1e/0x60
>    dev_dax_probe+0xce/0x2ec [device_dax]
>    dax_bus_probe+0x6d/0xc9
>    [... snip ...]
>    </TASK>
> 
> ...
>
>  arch/x86/include/asm/pgalloc.h          | 20 +++++++++++++
>  arch/x86/include/asm/pgtable_64_types.h |  3 ++
>  arch/x86/mm/init_64.c                   | 37 ++++++++++++++-----------
>  arch/x86/mm/kasan_init_64.c             |  8 +++---
>  include/asm-generic/pgalloc.h           | 16 +++++++++++
>  include/linux/pgtable.h                 | 17 ++++++++++++
>  include/linux/vmalloc.h                 | 16 -----------
>  mm/kasan/init.c                         | 10 +++----
>  mm/percpu.c                             |  4 +--
>  mm/sparse-vmemmap.c                     |  4 +--
>  10 files changed, 90 insertions(+), 45 deletions(-)

Are any other architectures likely to be affected by this flaw?

It's late for 6.16.  I'd propose that this series target 6.17 and once
merged, the cc:stable tags will take care of 6.16.x and earlier.

It's regrettable that the series contains some patches which are
cc:stable and some which are not.  Because 6.16.x and earlier will end
up getting only some of these patches, so we're backporting an untested
patch combination.  It would be better to prepare all this as two
series: one for backporting and the other not.

It's awkward that some of the cc:stable patches have a Fixes: and
others do not.  Exactly which kernel version(s) are we asking the
-stable maintainers to merge these patches into?

This looks somewhat more like an x86 series than an MM one.  I can take
it via mm.git with suitable x86 acks.  Or drop it from mm.git if it
goes into the x86 tree.  We can discuss that.

For now, I'll add this to mm.git's mm-new branch.  There it will get a
bit of exposure but it will be withheld from linux-next.  Once 6.17-rc1
is released I can move this into mm.git's mm-unstable branch to expose
it to linux-next testers.

Thanks.  I'll suppress the usual added-to-mm emails, save a few electrons.