[PATCH] arm64/mm: Check the requested PFN range during memoroy removal

[PATCH] arm64/mm: Check the requested PFN range during memoroy removal

[Richard Cheng]

prevent_memory_remove_notifier() advances pfn while checking whether the
range contains early memory. After the loop, pfn points to end_pfn, but
it is passed to can_unmap_without_split(). This checks the range
immediately after the requested memory instead of the range being
offlined.

Consequently, valid requests can be rejected with shifted address range,
while an unsafe request can be accepted when the following range is
unmapped. This was observed with CXL DAX memory, where the final memory
block was incorrectly allowed offline.

Pass arg->start_pfn so the leaf-split check examines the requested
range.

Fixes: 95a58852b0e5 ("arm64/mm: Reject memory removal that splits a kernel leaf mapping")
Signed-off-by: Richard Cheng <icheng@nvidia.com>
---
The bug occurred on a machine with CXL Type-3 device.
Branch: cxl-next

Before 95a58852b0e5:

"""
$ sudo echo offline > memory557056/state
write error: Operation not permitted
$ sudo dmesg
---[snip]---
[440008000000 440010000000] splits a leaf entry in linear map

$ sudo echo offline > memory558079/state
$ cat memory558079/state
offline
"""

After:
"""
$ sudo echo offline > memory557056/state
write error: Operation not permitted
[440000000000 440008000000] splits a leaf entry in linear map

$ sudo echo offline > memory558079/state
write error: Operation not permitted
[441ff8000000 442000000000] splits a leaf entry in linear map

My fix corrects the checked range and prevents the false acceptance.

Best regards,
Richard Cheng.
---
 arch/arm64/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a25d8beacc83..18a8b0d3714e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -2194,7 +2194,7 @@ static int prevent_memory_remove_notifier(struct notifier_block *nb,
 		}
 	}
 
-	if (!can_unmap_without_split(pfn, arg->nr_pages))
+	if (!can_unmap_without_split(arg->start_pfn, arg->nr_pages))
 		return NOTIFY_BAD;
 
 	return NOTIFY_OK;

base-commit: 5ca04f3ba91f1773bbd5da6d9c654ccc1ba7831d
-- 
2.43.0

Re: [PATCH] arm64/mm: Check the requested PFN range during memoroy removal

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `addr_splits_kernel_leaf()` violates ARM64 lockless page table walk guidelines by performing naked dereferences and failing to account for folded topologies.
--

--- Patch [1]: [PATCH] arm64/mm: Check the requested PFN range during memoroy removal ---
commit f65ddd9a8b39c91ebed9695bf77580886a5fd37c
Author: Richard Cheng <icheng@nvidia.com>

arm64/mm: Check the requested PFN range during memoroy removal

prevent_memory_remove_notifier() advances pfn while checking whether the
range contains early memory, which causes can_unmap_without_split() to check
the wrong range. This patch passes arg->start_pfn instead to ensure the
leaf-split check examines the requested range.

> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a25d8beacc831..18a8b0d3714ee 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -2194,7 +2194,7 @@ static int prevent_memory_remove_notifier(struct notifier_block *nb,
>  		}
>  	}
>  
> -	if (!can_unmap_without_split(pfn, arg->nr_pages))
> +	if (!can_unmap_without_split(arg->start_pfn, arg->nr_pages))

[Severity: High]
This is a pre-existing issue, but does addr_splits_kernel_leaf() (called by
can_unmap_without_split()) violate lockless page table walk guidelines?

In arch/arm64/mm/mmu.c:addr_splits_kernel_leaf():

	p4dp = p4d_offset(pgdp, addr);
	p4d = p4dp_get(p4dp);

When P4D is folded, p4d_offset() returns pgdp. p4dp_get() then issues a
second READ_ONCE(*pgdp), which can observe a transiently cleared state if
the entry is modified concurrently (e.g. during a Break-Before-Make
sequence).

Additionally, lower down in the same function:

	ptep = pte_offset_kernel(pmdp, addr);
	pte = __ptep_get(ptep);

Is it possible for pte_offset_kernel() to directly dereference the shared
pmdp pointer without READ_ONCE(), violating lockless walk atomicity
requirements?

If the lockless walk observes a transiently cleared page table entry, it
could incorrectly return false, falsely indicating that the memory range
does not split a leaf mapping. This would allow a memory hot-remove
operation to proceed and unmap an entire leaf, unmapping adjacent live
kernel memory and causing a synchronous data abort on the next kernel
access.

>  		return NOTIFY_BAD;
>  
>  	return NOTIFY_OK;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720020655.9607-1-icheng@nvidia.com?part=1

Re: [PATCH] arm64/mm: Check the requested PFN range during memoroy removal

[Anshuman Khandual]

On 20/07/26 7:36 AM, Richard Cheng wrote:
> prevent_memory_remove_notifier() advances pfn while checking whether the
> range contains early memory. After the loop, pfn points to end_pfn, but
> it is passed to can_unmap_without_split(). This checks the range
> immediately after the requested memory instead of the range being
> offlined.

can_unmap_without_split() ends up checking 'a memory range' after
the actual range being offlined, because pfn could have gone past
end_pfn by the time it exists the loop. This is wrong and was not
intended.

> 
> Consequently, valid requests can be rejected with shifted address range,
> while an unsafe request can be accepted when the following range is
> unmapped. This was observed with CXL DAX memory, where the final memory
> block was incorrectly allowed offline.

Agreed.
> 
> Pass arg->start_pfn so the leaf-split check examines the requested

Pass arg->start_pfn into can_unmap_without_split().
> range.

Although the explanations above are correct, the wording in the
commit message could have been better.
> 
> Fixes: 95a58852b0e5 ("arm64/mm: Reject memory removal that splits a kernel leaf mapping")

Correct commit ID for attribution.

> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> ---
> The bug occurred on a machine with CXL Type-3 device.
> Branch: cxl-next
> 
> Before 95a58852b0e5:
> 
> """
> $ sudo echo offline > memory557056/state
> write error: Operation not permitted
> $ sudo dmesg
> ---[snip]---
> [440008000000 440010000000] splits a leaf entry in linear map
> 
> $ sudo echo offline > memory558079/state
> $ cat memory558079/state
> offline
> """
> 
> After:
> """
> $ sudo echo offline > memory557056/state
> write error: Operation not permitted
> [440000000000 440008000000] splits a leaf entry in linear map
> 
> $ sudo echo offline > memory558079/state
> write error: Operation not permitted
> [441ff8000000 442000000000] splits a leaf entry in linear map

Seems exactly as would have been expected.
> 
> My fix corrects the checked range and prevents the false acceptance.

> 
> Best regards,
> Richard Cheng.
> ---
>  arch/arm64/mm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a25d8beacc83..18a8b0d3714e 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -2194,7 +2194,7 @@ static int prevent_memory_remove_notifier(struct notifier_block *nb,
>  		}
>  	}
>  
> -	if (!can_unmap_without_split(pfn, arg->nr_pages))
> +	if (!can_unmap_without_split(arg->start_pfn, arg->nr_pages))
>  		return NOTIFY_BAD;
>  
>  	return NOTIFY_OK;
> 
> base-commit: 5ca04f3ba91f1773bbd5da6d9c654ccc1ba7831d

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

Re: [PATCH] arm64/mm: Check the requested PFN range during memoroy removal

[Jonathan Cameron]

On Mon, 20 Jul 2026 10:06:55 +0800
Richard Cheng <icheng@nvidia.com> wrote:

Hi Richard, 

Please run a spell checker over your commit messages. 
"memory" in the patch description for example.

Fix itself looks correct to me.


> prevent_memory_remove_notifier() advances pfn while checking whether the
> range contains early memory. After the loop, pfn points to end_pfn, but
> it is passed to can_unmap_without_split(). This checks the range
> immediately after the requested memory instead of the range being
> offlined.
> 
> Consequently, valid requests can be rejected with shifted address range,
> while an unsafe request can be accepted when the following range is
> unmapped. This was observed with CXL DAX memory, where the final memory
> block was incorrectly allowed offline.
> 
> Pass arg->start_pfn so the leaf-split check examines the requested
> range.
> 
> Fixes: 95a58852b0e5 ("arm64/mm: Reject memory removal that splits a kernel leaf mapping")
> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> ---
> The bug occurred on a machine with CXL Type-3 device.
> Branch: cxl-next
> 
> Before 95a58852b0e5:
> 
> """
> $ sudo echo offline > memory557056/state
> write error: Operation not permitted
> $ sudo dmesg
> ---[snip]---
> [440008000000 440010000000] splits a leaf entry in linear map
> 
> $ sudo echo offline > memory558079/state
> $ cat memory558079/state
> offline
> """
> 
> After:
> """
> $ sudo echo offline > memory557056/state
> write error: Operation not permitted
> [440000000000 440008000000] splits a leaf entry in linear map
> 
> $ sudo echo offline > memory558079/state
> write error: Operation not permitted
> [441ff8000000 442000000000] splits a leaf entry in linear map
> 
> My fix corrects the checked range and prevents the false acceptance.
> 
> Best regards,
> Richard Cheng.
> ---
>  arch/arm64/mm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a25d8beacc83..18a8b0d3714e 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -2194,7 +2194,7 @@ static int prevent_memory_remove_notifier(struct notifier_block *nb,
>  		}
>  	}
>  
> -	if (!can_unmap_without_split(pfn, arg->nr_pages))
> +	if (!can_unmap_without_split(arg->start_pfn, arg->nr_pages))
>  		return NOTIFY_BAD;
>  
>  	return NOTIFY_OK;
> 
> base-commit: 5ca04f3ba91f1773bbd5da6d9c654ccc1ba7831d