[PATCH v7 5/9] memblock: introduce MEMBLOCK_NODUMP flag

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: lockless mutation of memblock.memory causes UAF in concurrent readers
--

commit 3e0d4f57949330268c708beeb66dc1c0fb65db32
Author: Wandun Chen <chenwandun at lixiang.com>
Subject: memblock: introduce MEMBLOCK_NODUMP flag

This patch introduces the MEMBLOCK_NODUMP flag to mark memory regions that
should be excluded from kdump vmcores. It also adds logic to clear this flag
when reserved memory, such as the initrd, is freed so the memory can be
properly reused.

> diff --git a/mm/memblock.c b/mm/memblock.c
> index ea0de4b5f3568..48cabfe5cdf16 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
[ ... ]
> @@ -949,9 +951,13 @@ unsigned long free_reserved_area(void *start, void *end, int poison, const char
>  	}
>  
>  	if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
> -		if (start_pa < end_pa)
> +		if (start_pa < end_pa) {
>  			memblock_remove_range(&memblock.reserved,
>  					      start_pa, end_pa - start_pa);
> +
> +			if (IS_ENABLED(CONFIG_CRASH_DUMP))
> +				memblock_clear_nodump(start_pa, end_pa - start_pa);
> +		}
>  	}

[Severity: High]
Could this lockless mutation of memblock.memory race with concurrent readers?

This code path is triggered during asynchronous initrd freeing
(e.g., via do_populate_rootfs using async_schedule_domain).

Calling memblock_clear_nodump() modifies the memblock.memory array locklessly
via memblock_setclr_flag() and memblock_isolate_range().
memblock_isolate_range() can split ranges using memmove(), which disrupts
array ordering, and can even call memblock_double_array() which kfree()s
the old array.

Concurrently, subsystems rely on memblock.memory being immutable after early
boot. For example, on ARM64, ioremap() calls pfn_is_map_memory(), which
performs a lockless binary search (memblock_search()) directly on
memblock.memory.regions.

If memblock_clear_nodump() splits or reallocates the array while ioremap()
is executing during driver probes, could this result in a use-after-free
on the freed array or an out-of-bounds access from broken binary search
invariants?

[ ... ]
> @@ -995,8 +1001,11 @@ int __init_memblock memblock_phys_free(phys_addr_t base, phys_addr_t size)
>  
>  	kmemleak_free_part_phys(base, size);
>  
> -	if (!slab_is_available() || IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
> +	if (!slab_is_available() || IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
>  		ret = memblock_remove_range(&memblock.reserved, base, size);
> +		if (IS_ENABLED(CONFIG_CRASH_DUMP))
> +			memblock_clear_nodump(base, size);
> +	}

[Severity: High]
Similar to the above, does this introduce the same lockless mutation risk
when called during runtime module unloads or CMA frees?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922084256.1515554-1-chenwandun1@gmail.com?part=5