Re: [PATCH v5] dax/bus: Fix Device DAX range alignment validation

[Andrew Morton]

On Sat, 24 Oct 2026 19:25:55 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:

> Only range sizes are currently validated against dev_dax->align. A
> dynamic device can therefore select a large-page alignment and allocate a
> range whose start is not naturally aligned.
> 
> Sashiko found that memmap_init_zone_device() could then initialize the
> struct pages with a large-page order for a physical range that is not
> naturally aligned. A subsequent write to a userspace mapping then
> triggered a kernel panic in testing.
> 
> The automatic resize path can also split a size-aligned request across
> arbitrary free gaps. When devices with different alignments fragment a
> region, this can extend a range by less than the device alignment. A later
> allocation then fails, leaving the failed resize partially applied.
> 
> Initialize the device alignment before its first allocation. Validate both
> the start and size of allocated and adjusted ranges. Use the same
> aligned-gap iterator for free-space accounting and range allocation so the
> pre-check and allocation path cannot diverge. Skip unusable gaps and
> serialize size validation with alignment updates.
> 
> Static Device DAX already has a pre-populated pgmap whose full range was
> validated against memremap_compat_align(). Its usable data range may begin
> after namespace metadata, so require only dev_dax->align for static
> devices. Dynamic Device DAX builds its pgmap from the allocated ranges and
> must continue to satisfy both alignments.

Thanks.  This is now a must-have for 7.4.

I suggest that the changelog mention that the bug becomes hittable once
your series "mm: Unify device DAX and HugeTLB vmemmap population paths"
exposes it.  That's 

4b77739fe789 ("mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX").

I intend to send this to Linus next week.

Maybe also a Fixes: 4b77739fe789.  That series didn't create the bug,
but this data provides notification to people who are backporting this
series (unlikely) "hey, you need to add this fix as well".

Also
Reported-by: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx>
Closes: https://lore.kernel.org/wlrkqqvg.ritesh.list@xxxxxxxxx

I don't believe that Ritesh has tested this?  He wasn't cc'ed...