All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Radhey Shyam Pandey" <radhey.shyam.pandey@amd.com>,
	akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
	liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, baoquan.he@linux.dev,
	pasha.tatashin@soleen.com, pratyush@kernel.org, graf@amazon.com
Cc: kexec@lists.infradead.org
Subject: Re: [RFC PATCH 2/2] mm/cma: reject CMA areas that overlap the kernel image
Date: Wed, 14 Oct 2026 15:09:43 +0000	[thread overview]
Message-ID: <sashiko-outbox-171457@kernel.org> (raw)
In-Reply-To: <20261014145731.3431527-3-radhey.shyam.pandey@amd.com>

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@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


      reply	other threads:[~2026-10-14 15:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 14:57 [RFC PATCH 0/2] kexec,mm/cma: do not run the next kernel from a fixed-base CMA area Radhey Shyam Pandey
2026-10-14 14:57 ` [RFC PATCH 1/2] kexec: do not place the next kernel in a fixed-address " Radhey Shyam Pandey
2026-10-14 15:07   ` sashiko-bot
2026-10-14 14:57 ` [RFC PATCH 2/2] mm/cma: reject CMA areas that overlap the kernel image Radhey Shyam Pandey
2026-10-14 15:09   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-171457@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --cc=david@kernel.org \
    --cc=graf@amazon.com \
    --cc=kexec@lists.infradead.org \
    --cc=liam@infradead.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.