[PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[liulhong617]

From: liulhong617 <liulhong617@gmail.com>

When reserved-memory regions with the "no-map" property are not
page-aligned, the kernel may accidentally map them into the linear
mapping, contradicting the no-map semantics.

The root cause is a mismatch between /proc/iomem's address boundaries
and the actual page table mapping boundaries:

1. /proc/iomem derives its ranges from memblock via
   memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn,
   which perform PFN rounding so the displayed boundaries are
   page-aligned. This gives the impression that the no-map region
   occupies whole pages.

2. However, memblock_mark_nomap() splits memblock.memory regions at
   exact byte boundaries (memblock_isolate_range preserves raw DT
   base/size with no alignment). When for_each_mem_range iterates the
   non-NOMAP regions adjacent to a no-map region, it returns start/end
   values that are NOT page-aligned — they are the precise byte
   boundaries from the memblock split.

3. These sub-page-aligned values are passed to
   __create_pgd_mapping_locked(), which does:
     phys &= PAGE_MASK;
     addr = virt & PAGE_MASK;
     end = PAGE_ALIGN(virt + size);
   The downward rounding of phys via PAGE_MASK extends the mapped
   range backward into the adjacent no-map region, effectively
   including no-map memory in the linear mapping.

For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000,
size=0x8000, no-map) causes for_each_mem_range to return
start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK,
the actual mapping starts at 0xA2000000 — the entire no-map region is
incorrectly mapped.

Fix this by rounding the mappable range inward to PAGE_SIZE boundaries
before passing it to __map_memblock: start is rounded UP and end is
rounded DOWN. This ensures the mapped area never overlaps with adjacent
no-map regions. The cost is at most one page of unmapped gap at each
boundary, which is preferable to violating no-map semantics.

Signed-off-by: liulhong617 <liulhong617@gmail.com>
---
 arch/arm64/mm/mmu.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dd85e093f..bc8ac7622 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1175,6 +1175,20 @@ static void __init map_mem(pgd_t *pgdp)
 	for_each_mem_range(i, &start, &end) {
 		if (start >= end)
 			break;
+		/*
+		 * for_each_mem_range may return sub-page-aligned boundaries
+		 * after memblock_mark_nomap() splits regions at byte precision.
+		 * __create_pgd_mapping_locked aligns phys down to PAGE_MASK,
+		 * which could accidentally map no-map memory on the boundary.
+		 * Round the mappable range inward: start UP, end DOWN, so
+		 * that the mapped area never overlaps with adjacent no-map
+		 * regions. The cost is at most one page of unmapped gap at
+		 * each boundary.
+		 */
+		start = PAGE_ALIGN(start);
+		end = end & PAGE_MASK;
+		if (start >= end)
+			continue;
 		/*
 		 * The linear map must allow allocation tags reading/writing
 		 * if MTE is present. Otherwise, it has the same attributes as
-- 
2.34.1

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Will Deacon]

[+Ard]

On Wed, May 13, 2026 at 09:02:55AM +0800, liulhong617@163.com wrote:
> From: liulhong617 <liulhong617@gmail.com>
> 
> When reserved-memory regions with the "no-map" property are not
> page-aligned, the kernel may accidentally map them into the linear
> mapping, contradicting the no-map semantics.

Crikey, I wonder what the semantics are for "no-map" if the region isn't
page aligned? If the remaining part of the page is advertised as memory
but doesn't have the "no-map" property, then we can't really satisfy
what we're being asked to do.

> The root cause is a mismatch between /proc/iomem's address boundaries
> and the actual page table mapping boundaries:
> 
> 1. /proc/iomem derives its ranges from memblock via
>    memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn,
>    which perform PFN rounding so the displayed boundaries are
>    page-aligned. This gives the impression that the no-map region
>    occupies whole pages.
> 
> 2. However, memblock_mark_nomap() splits memblock.memory regions at
>    exact byte boundaries (memblock_isolate_range preserves raw DT
>    base/size with no alignment). When for_each_mem_range iterates the
>    non-NOMAP regions adjacent to a no-map region, it returns start/end
>    values that are NOT page-aligned — they are the precise byte
>    boundaries from the memblock split.
> 
> 3. These sub-page-aligned values are passed to
>    __create_pgd_mapping_locked(), which does:
>      phys &= PAGE_MASK;
>      addr = virt & PAGE_MASK;
>      end = PAGE_ALIGN(virt + size);
>    The downward rounding of phys via PAGE_MASK extends the mapped
>    range backward into the adjacent no-map region, effectively
>    including no-map memory in the linear mapping.
> 
> For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000,
> size=0x8000, no-map) causes for_each_mem_range to return
> start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK,
> the actual mapping starts at 0xA2000000 — the entire no-map region is
> incorrectly mapped.
> 
> Fix this by rounding the mappable range inward to PAGE_SIZE boundaries
> before passing it to __map_memblock: start is rounded UP and end is
> rounded DOWN. This ensures the mapped area never overlaps with adjacent
> no-map regions. The cost is at most one page of unmapped gap at each
> boundary, which is preferable to violating no-map semantics.
> 
> Signed-off-by: liulhong617 <liulhong617@gmail.com>
> ---
>  arch/arm64/mm/mmu.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index dd85e093f..bc8ac7622 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1175,6 +1175,20 @@ static void __init map_mem(pgd_t *pgdp)
>  	for_each_mem_range(i, &start, &end) {
>  		if (start >= end)
>  			break;
> +		/*
> +		 * for_each_mem_range may return sub-page-aligned boundaries
> +		 * after memblock_mark_nomap() splits regions at byte precision.
> +		 * __create_pgd_mapping_locked aligns phys down to PAGE_MASK,
> +		 * which could accidentally map no-map memory on the boundary.
> +		 * Round the mappable range inward: start UP, end DOWN, so
> +		 * that the mapped area never overlaps with adjacent no-map
> +		 * regions. The cost is at most one page of unmapped gap at
> +		 * each boundary.
> +		 */
> +		start = PAGE_ALIGN(start);
> +		end = end & PAGE_MASK;
> +		if (start >= end)
> +			continue;

Maybe I'm over-worrying here, but I've seen firmware describe parts of
memory as lots of small, adjacent regions in some cases and so I'm
worried we'd fail to map the pages with this change.

I'd be more in favour of detecting sub-page sized "no-map" regions that
are adjacent to normal memory regions, emitting a warning/firmware taint
and then doing... precisely nothing about it. What practical issues are
you seeing on your system?

Will

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Lianghong Liu]

Hi Will,

Thanks for the review. Quick answers to the two open questions.

## What I'm seeing on my system

64K pages (PAGE_SHIFT=16). A no-map reserved region at 0xA2000000 with
size 0x8000 (32 KiB, sub-page). The linear map should skip that hole and
start at 0xA2008000; instead it starts at 0xA2000000 — the whole no-map
region is mapped with PAGE_KERNEL. Debug print in
__create_pgd_mapping_locked():

  create_pgd_mapping: phys 0xa2008000 ...
    after PAGE_MASK align: phys 0xa2000000 - 0xab000000   <- start rounded DOWN into no-map

Cause: for_each_mem_range skips MEMBLOCK_NOMAP regions via
should_skip_region(), but memblock_mark_nomap() splits at byte
boundaries in memblock_isolate_range() (rgn->base = base), so the
*adjacent* region is returned with a sub-page-aligned start/end. That
value then hits
  phys &= PAGE_MASK;
in __create_pgd_mapping_locked(), which rounds the start DOWN and pulls
the mapping back into the no-map page.

So this is a real isolation break, not cosmetic: no-map memory the
firmware asked to leave untouched ends up read/writable in the linear
region.

## On "we might fail to map legitimately mappable pages"

The inward rounding can't lose any page the allocator owns. The buddy
release path uses the exact same inward PFN rounding in
__free_memory_core():
  start_pfn = PFN_UP(start);
  end_pfn   = min(PFN_DOWN(end), max_low_pfn);
  if (start_pfn >= end_pfn) return 0;

So the sub-page sliver at a no-map boundary is never handed to the
allocator and has no struct page backing it — the linear map currently
over-maps bytes the allocator already doesn't manage. The patch just
aligns the linear map to the allocator's own notion of the region, so
no mappable page goes unmapped that isn't already unmapped today.

## On "warn + do nothing"

Happy to add a WARN_ON for a sub-page no-map region adjacent to mappable
memory — useful as a firmware-compat signal — but a warning alone leaves
the no-map memory mapped, so I'd keep the inward rounding with it. If
that reasoning holds I'll send v2 with the WARN added.

Thanks,
Lianghong Liu

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Will Deacon]

On Mon, Jul 27, 2026 at 09:55:58AM +0800, Lianghong Liu wrote:
> Thanks for the review. Quick answers to the two open questions.
> 
> ## What I'm seeing on my system
> 
> 64K pages (PAGE_SHIFT=16). A no-map reserved region at 0xA2000000 with
> size 0x8000 (32 KiB, sub-page). The linear map should skip that hole and
> start at 0xA2008000; instead it starts at 0xA2000000 — the whole no-map
> region is mapped with PAGE_KERNEL. Debug print in
> __create_pgd_mapping_locked():
> 
>   create_pgd_mapping: phys 0xa2008000 ...
>     after PAGE_MASK align: phys 0xa2000000 - 0xab000000   <- start rounded DOWN into no-map
> 
> Cause: for_each_mem_range skips MEMBLOCK_NOMAP regions via
> should_skip_region(), but memblock_mark_nomap() splits at byte
> boundaries in memblock_isolate_range() (rgn->base = base), so the
> *adjacent* region is returned with a sub-page-aligned start/end. That
> value then hits
>   phys &= PAGE_MASK;
> in __create_pgd_mapping_locked(), which rounds the start DOWN and pulls
> the mapping back into the no-map page.
> 
> So this is a real isolation break, not cosmetic: no-map memory the
> firmware asked to leave untouched ends up read/writable in the linear
> region.
> 
> ## On "we might fail to map legitimately mappable pages"
> 
> The inward rounding can't lose any page the allocator owns. The buddy
> release path uses the exact same inward PFN rounding in
> __free_memory_core():
>   start_pfn = PFN_UP(start);
>   end_pfn   = min(PFN_DOWN(end), max_low_pfn);
>   if (start_pfn >= end_pfn) return 0;

Sorry, but I don't understand how this has anything to do with the
question I asked. It looks like you just fed my reply to an LLVM and
pasted the response here.

I'm not convinced your patch is correct and I don't understand your
reply.

Will

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Ard Biesheuvel]

On Thu, 16 Jul 2026, at 17:01, Will Deacon wrote:
> [+Ard]
>
> On Wed, May 13, 2026 at 09:02:55AM +0800, liulhong617@163.com wrote:
>> From: liulhong617 <liulhong617@gmail.com>
>> 
>> When reserved-memory regions with the "no-map" property are not
>> page-aligned, the kernel may accidentally map them into the linear
>> mapping, contradicting the no-map semantics.
>
> Crikey, I wonder what the semantics are for "no-map" if the region isn't
> page aligned? If the remaining part of the page is advertised as memory
> but doesn't have the "no-map" property, then we can't really satisfy
> what we're being asked to do.
>
>> The root cause is a mismatch between /proc/iomem's address boundaries
>> and the actual page table mapping boundaries:
>> 
>> 1. /proc/iomem derives its ranges from memblock via
>>    memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn,
>>    which perform PFN rounding so the displayed boundaries are
>>    page-aligned. This gives the impression that the no-map region
>>    occupies whole pages.
>> 
>> 2. However, memblock_mark_nomap() splits memblock.memory regions at
>>    exact byte boundaries (memblock_isolate_range preserves raw DT
>>    base/size with no alignment). When for_each_mem_range iterates the
>>    non-NOMAP regions adjacent to a no-map region, it returns start/end
>>    values that are NOT page-aligned — they are the precise byte
>>    boundaries from the memblock split.
>> 
>> 3. These sub-page-aligned values are passed to
>>    __create_pgd_mapping_locked(), which does:
>>      phys &= PAGE_MASK;
>>      addr = virt & PAGE_MASK;
>>      end = PAGE_ALIGN(virt + size);
>>    The downward rounding of phys via PAGE_MASK extends the mapped
>>    range backward into the adjacent no-map region, effectively
>>    including no-map memory in the linear mapping.
>> 
>> For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000,
>> size=0x8000, no-map) causes for_each_mem_range to return
>> start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK,
>> the actual mapping starts at 0xA2000000 — the entire no-map region is
>> incorrectly mapped.
>> 
>> Fix this by rounding the mappable range inward to PAGE_SIZE boundaries
>> before passing it to __map_memblock: start is rounded UP and end is
>> rounded DOWN. This ensures the mapped area never overlaps with adjacent
>> no-map regions. The cost is at most one page of unmapped gap at each
>> boundary, which is preferable to violating no-map semantics.
>> 
>> Signed-off-by: liulhong617 <liulhong617@gmail.com>
>> ---
>>  arch/arm64/mm/mmu.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>> 
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index dd85e093f..bc8ac7622 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1175,6 +1175,20 @@ static void __init map_mem(pgd_t *pgdp)
>>  	for_each_mem_range(i, &start, &end) {
>>  		if (start >= end)
>>  			break;
>> +		/*
>> +		 * for_each_mem_range may return sub-page-aligned boundaries
>> +		 * after memblock_mark_nomap() splits regions at byte precision.
>> +		 * __create_pgd_mapping_locked aligns phys down to PAGE_MASK,
>> +		 * which could accidentally map no-map memory on the boundary.
>> +		 * Round the mappable range inward: start UP, end DOWN, so
>> +		 * that the mapped area never overlaps with adjacent no-map
>> +		 * regions. The cost is at most one page of unmapped gap at
>> +		 * each boundary.
>> +		 */
>> +		start = PAGE_ALIGN(start);
>> +		end = end & PAGE_MASK;
>> +		if (start >= end)
>> +			continue;
>
> Maybe I'm over-worrying here, but I've seen firmware describe parts of
> memory as lots of small, adjacent regions in some cases and so I'm
> worried we'd fail to map the pages with this change.
>
> I'd be more in favour of detecting sub-page sized "no-map" regions that
> are adjacent to normal memory regions, emitting a warning/firmware taint
> and then doing... precisely nothing about it. What practical issues are
> you seeing on your system?
>

I think this change is conceptually sound: for_each_mem_range() will present
a set of coalesced memory ranges, so any sub-[OS-]page regions will have
been stitched together by this time. The only sane way to handle no-map
regions is to round them outward, even if this might result in issues if the
bootloader is being thick and e.g., puts part of the initramfs (which the
kernel assumes is accessible via the linear map) in a region that remains
unmapped as a result.

I do wonder if it wouldn't be better if __create_pgd_mapping_locked() did
inward rounding, or even better, did no rounding at all, and left it to the
callers to perform the rounding.

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Will Deacon]

On Tue, Aug 04, 2026 at 05:24:33PM +0300, Ard Biesheuvel wrote:
> 
> On Thu, 16 Jul 2026, at 17:01, Will Deacon wrote:
> > [+Ard]
> >
> > On Wed, May 13, 2026 at 09:02:55AM +0800, liulhong617@163.com wrote:
> >> From: liulhong617 <liulhong617@gmail.com>
> >> 
> >> When reserved-memory regions with the "no-map" property are not
> >> page-aligned, the kernel may accidentally map them into the linear
> >> mapping, contradicting the no-map semantics.
> >
> > Crikey, I wonder what the semantics are for "no-map" if the region isn't
> > page aligned? If the remaining part of the page is advertised as memory
> > but doesn't have the "no-map" property, then we can't really satisfy
> > what we're being asked to do.
> >
> >> The root cause is a mismatch between /proc/iomem's address boundaries
> >> and the actual page table mapping boundaries:
> >> 
> >> 1. /proc/iomem derives its ranges from memblock via
> >>    memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn,
> >>    which perform PFN rounding so the displayed boundaries are
> >>    page-aligned. This gives the impression that the no-map region
> >>    occupies whole pages.
> >> 
> >> 2. However, memblock_mark_nomap() splits memblock.memory regions at
> >>    exact byte boundaries (memblock_isolate_range preserves raw DT
> >>    base/size with no alignment). When for_each_mem_range iterates the
> >>    non-NOMAP regions adjacent to a no-map region, it returns start/end
> >>    values that are NOT page-aligned — they are the precise byte
> >>    boundaries from the memblock split.
> >> 
> >> 3. These sub-page-aligned values are passed to
> >>    __create_pgd_mapping_locked(), which does:
> >>      phys &= PAGE_MASK;
> >>      addr = virt & PAGE_MASK;
> >>      end = PAGE_ALIGN(virt + size);
> >>    The downward rounding of phys via PAGE_MASK extends the mapped
> >>    range backward into the adjacent no-map region, effectively
> >>    including no-map memory in the linear mapping.
> >> 
> >> For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000,
> >> size=0x8000, no-map) causes for_each_mem_range to return
> >> start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK,
> >> the actual mapping starts at 0xA2000000 — the entire no-map region is
> >> incorrectly mapped.
> >> 
> >> Fix this by rounding the mappable range inward to PAGE_SIZE boundaries
> >> before passing it to __map_memblock: start is rounded UP and end is
> >> rounded DOWN. This ensures the mapped area never overlaps with adjacent
> >> no-map regions. The cost is at most one page of unmapped gap at each
> >> boundary, which is preferable to violating no-map semantics.
> >> 
> >> Signed-off-by: liulhong617 <liulhong617@gmail.com>
> >> ---
> >>  arch/arm64/mm/mmu.c | 14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >> 
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index dd85e093f..bc8ac7622 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -1175,6 +1175,20 @@ static void __init map_mem(pgd_t *pgdp)
> >>  	for_each_mem_range(i, &start, &end) {
> >>  		if (start >= end)
> >>  			break;
> >> +		/*
> >> +		 * for_each_mem_range may return sub-page-aligned boundaries
> >> +		 * after memblock_mark_nomap() splits regions at byte precision.
> >> +		 * __create_pgd_mapping_locked aligns phys down to PAGE_MASK,
> >> +		 * which could accidentally map no-map memory on the boundary.
> >> +		 * Round the mappable range inward: start UP, end DOWN, so
> >> +		 * that the mapped area never overlaps with adjacent no-map
> >> +		 * regions. The cost is at most one page of unmapped gap at
> >> +		 * each boundary.
> >> +		 */
> >> +		start = PAGE_ALIGN(start);
> >> +		end = end & PAGE_MASK;
> >> +		if (start >= end)
> >> +			continue;
> >
> > Maybe I'm over-worrying here, but I've seen firmware describe parts of
> > memory as lots of small, adjacent regions in some cases and so I'm
> > worried we'd fail to map the pages with this change.
> >
> > I'd be more in favour of detecting sub-page sized "no-map" regions that
> > are adjacent to normal memory regions, emitting a warning/firmware taint
> > and then doing... precisely nothing about it. What practical issues are
> > you seeing on your system?
> >
> 
> I think this change is conceptually sound: for_each_mem_range() will present
> a set of coalesced memory ranges, so any sub-[OS-]page regions will have
> been stitched together by this time.

Aha, thanks, that's the part I was missing.

> I do wonder if it wouldn't be better if __create_pgd_mapping_locked() did
> inward rounding, or even better, did no rounding at all, and left it to the
> callers to perform the rounding.

I can take this patch for now but maybe somebody can have a play with
that in the future.

Will

Re: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory

[Will Deacon]

On Wed, 13 May 2026 09:02:55 +0800, liulhong617@163.com wrote:
> When reserved-memory regions with the "no-map" property are not
> page-aligned, the kernel may accidentally map them into the linear
> mapping, contradicting the no-map semantics.
> 
> The root cause is a mismatch between /proc/iomem's address boundaries
> and the actual page table mapping boundaries:
> 
> [...]

Applied to arm64 (for-next/mm), thanks!

[1/1] arm64: mm: fix accidental linear mapping of no-map reserved memory
      https://git.kernel.org/arm64/c/7ace06a01efa

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev