linux-kernel - Re: [PATCH v5 1/5] mm/zone_device: Reinitialize large zone device private folios

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: <20260114184042.64fc3df3e43e6e62870bb705@linux-foundation.org>
Date: Wed, 14 Jan 2026 18:40:42 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Matthew Brost <matthew.brost@...el.com>
Cc: Francois Dugast <francois.dugast@...el.com>,
 <intel-xe@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>, Zi Yan
 <ziy@...dia.com>, Alistair Popple <apopple@...dia.com>, adhavan Srinivasan
 <maddy@...ux.ibm.com>, Nicholas Piggin <npiggin@...il.com>, Michael
 Ellerman <mpe@...erman.id.au>, "Christophe Leroy (CS GROUP)"
 <chleroy@...nel.org>, Felix Kuehling <Felix.Kuehling@....com>, Alex Deucher
 <alexander.deucher@....com>, Christian König
 <christian.koenig@....com>, David Airlie <airlied@...il.com>, Simona Vetter
 <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann
 <tzimmermann@...e.de>, Lyude Paul <lyude@...hat.com>, Danilo Krummrich
 <dakr@...nel.org>, "David Hildenbrand" <david@...nel.org>, Oscar Salvador
 <osalvador@...e.de>, "Jason Gunthorpe" <jgg@...pe.ca>, Leon Romanovsky
 <leon@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka
 <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, "Suren Baghdasaryan"
 <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, "Balbir Singh"
 <balbirs@...dia.com>, <linuxppc-dev@...ts.ozlabs.org>,
 <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <amd-gfx@...ts.freedesktop.org>, <nouveau@...ts.freedesktop.org>,
 <linux-mm@...ck.org>, <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH v5 1/5] mm/zone_device: Reinitialize large zone device
 private folios

On Wed, 14 Jan 2026 15:51:16 -0800 Matthew Brost <matthew.brost@...el.com> wrote:

> On Wed, Jan 14, 2026 at 03:34:21PM -0800, Matthew Brost wrote:
> > On Wed, Jan 14, 2026 at 01:48:25PM -0800, Andrew Morton wrote:
> > > On Wed, 14 Jan 2026 20:19:52 +0100 Francois Dugast <francois.dugast@...el.com> wrote:
> > > 
> > > > Reinitialize metadata for large zone device private folios in
> > > > zone_device_page_init prior to creating a higher-order zone device
> > > > private folio. This step is necessary when the folio’s order changes
> > > > dynamically between zone_device_page_init calls to avoid building a
> > > > corrupt folio. As part of the metadata reinitialization, the dev_pagemap
> > > > must be passed in from the caller because the pgmap stored in the folio
> > > > page may have been overwritten with a compound head.
> > > 
> > > Thanks.  What are the worst-case userspace-visible effects of the bug?
> > 
> > If you reallocate a subset of pages from what was originally a large
> > device folio, the pgmap mapping becomes invalid because it was
> > overwritten by the compound head, and this can crash the kernel.
> > 
> > Alternatively, consider the case where the original folio had an order
> > of 9 and _nr_pages was set. If you then reallocate the folio plus one as
> 
> s/_nr_pages/the order was encoded the page flags.
> 
> ...
>
> s/best to have kernel/best to not have kernels
> 

Great, thanks.  I pasted all the above into the changelog to help
explain our reasons.  I'll retain the patch in mm-hotfixes, targeting
6.19-rcX.  The remainder of the series is DRM stuff, NotMyProblem.  I
assume that getting this into 6.19-rcX is helpful to DRM - if not, and
if taking this via the DRM tree is preferable then let's discuss.

Can reviewers please take a look at this reasonably promptly?

btw, this patch uses

+		struct folio *new_folio = (struct folio *)new_page;

Was page_folio() unsuitable?