[RFC PATCH 2/2] mm/cma: reject CMA areas that overlap the kernel image

sashiko-bot at kernel.org sashiko-bot at kernel.org
Wed Oct 14 08:09:43 PDT 2026


Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] mm: integer overflow in CMA kernel overlap check bypasses protection
--

commit af398e11f427511d4d7335b0e8810e798dcdd794
Author: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>

mm/cma: reject CMA areas that overlap the kernel image

This commit adds an explicit check in cma_init_reserved_mem() to ensure
that initialized CMA areas do not overlap with the kernel image. This
prevents scenarios where an overlap clears PageReserved on the kernel's
own text and data, releasing them to the page allocator.

> diff --git a/mm/cma.c b/mm/cma.c
> index 1f4d3d48a3bb9..32b799a3f5c8f 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
[ ... ]
> @@ -68,6 +70,11 @@ bool cma_has_fixed_base(const struct cma *cma)
>  	return test_bit(CMA_FIXED_BASE, &cma->flags);
>  }
>  
> +static bool cma_overlaps_kernel_image(phys_addr_t base, phys_addr_t size)
> +{
> +	return base < __pa_symbol(_end) && __pa_symbol(_text) < base + size;

[Severity: Critical]
Can a maliciously large size cause an integer overflow here?

If a malformed huge size is passed down from an untrusted source (like a
device tree overlay), base + size could wrap around in a 32-bit phys_addr_t.
This would cause __pa_symbol(_text) < base + size to evaluate to false,
completely bypassing the kernel image protection.

> +}
> +
>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>  					     unsigned int align_order)
>  {
> @@ -295,6 +302,22 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  	if (!size || !memblock_is_region_reserved(base, size))
>  		return -EINVAL;

[Severity: Critical]
Does memblock_is_region_reserved() cap the size strictly internally?

Since size is passed by value, any capping inside memblock_is_region_reserved()
or memblock_reserve() leaves the caller's uncapped size unchanged.

The unmodified huge size then continues down to cma_overlaps_kernel_image(),
leading to the overflow described above. This could bypass the check entirely,
allowing subsequent processing to clear PageReserved on live kernel text pages.

>  
> +	/*
> +	 * The area being already reserved is expected here, so an overlap with
> +	 * the kernel image cannot be told apart from the normal case by looking
> +	 * at memblock alone. Check for it explicitly: activating such an area
> +	 * clears PageReserved on the kernel's own text and data and releases
> +	 * them to the page allocator.
> +	 */
> +	if (cma_overlaps_kernel_image(base, size)) {
> +		phys_addr_t text = __pa_symbol(_text);
> +		phys_addr_t end = __pa_symbol(_end);
> +
> +		pr_err("area %s (%pa, size %pa) overlaps kernel image [%pa-%pa]\n",
> +		       name ?: "(unnamed)", &base, &size, &text, &end);
> +		return -EBUSY;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014145731.3431527-1-radhey.shyam.pandey@amd.com?part=2



More information about the kexec mailing list