From: Mike Rapoport <rppt@kernel.org>
To: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
liam@infradead.org, vbabka@kernel.org, surenb@google.com,
mhocko@suse.com, baoquan.he@linux.dev, pasha.tatashin@soleen.com,
pratyush@kernel.org, graf@amazon.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [RFC PATCH 2/2] mm/cma: reject CMA areas that overlap the kernel image
Date: Thu, 29 Oct 2026 09:42:44 +0200 [thread overview]
Message-ID: <auL49EhsNL4jc1o3@kernel.org> (raw)
In-Reply-To: <20261014145731.3431527-3-radhey.shyam.pandey@amd.com>
On Wed, Oct 14, 2026 at 08:27:31PM +0530, Radhey Shyam Pandey wrote:
> cma_init_reserved_mem() takes a base address chosen by its caller and
> requires that the range already be reserved. That makes an overlap with
> the kernel image indistinguishable from the normal case by looking at
> memblock alone, yet such an area is fatal: cma_activate_area() hands it
> to init_cma_reserved_pageblock(), which unconditionally clears
> PageReserved on every page and frees them into MIGRATE_CMA, overriding
> the memblock_reserve() of [_text, _end) that the architecture installed.
> Those pages satisfy ordinary movable allocations from that point on, so
> userspace is handed live kernel text.
>
> The preceding patch closes the way this is reachable today, where a
> kexec'd kernel runs from inside the default CMA area and then declares
> the range it is executing from as a shared-dma-pool. On a VEK385 that
> reproduced within ~300ms of /sbin/init starting, as a copy-on-write
> fault writing to the read-only linear alias of .text:
>
> Unable to handle kernel write to read-only memory at virtual address ffff00084030c000
> Call trace:
> copy_page+0x48/0xc4 (P)
> copy_user_highpage+0x14/0x30
> __handle_mm_fault+0x318/0x1340
>
> Dynamically placed areas cannot hit this: __cma_declare_contiguous_nid()
> either rejects a fixed base that is already reserved, or picks an address
> itself and so avoids the kernel image. Only a caller that passes a base
> chosen elsewhere can, so check for the overlap explicitly rather than
> leave the next such caller to corrupt the kernel silently.
>
> Note that failing here is not by itself sufficient for a device-tree
> pool. fdt_init_reserved_mem_node() responds to an error from a non-nomap
> region by calling memblock_phys_free() on the whole range, which drops
> the kernel image's own reservation along with it, so the pages are still
> released - as plain free memory rather than MIGRATE_CMA. Callers that
> keep their reservation on failure, such as powerpc's fadump_cma_init(),
> are fully protected. For the device-tree path this is a diagnostic and a
> second line of defence behind the preceding patch.
>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> mm/cma.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 1f4d3d48a3bb..32b799a3f5c8 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -31,6 +31,8 @@
> #include <linux/kmemleak.h>
> #include <trace/events/cma.h>
>
> +#include <asm/sections.h>
> +
> #include "internal.h"
> #include "cma.h"
> #include "mm_init.h"
> @@ -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;
> +}
We have helpers for that in include/asm-generic/sections.h
> +
> 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;
>
> + /*
> + * 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.
> + */
I don't think this comment is useful, the check itself is clear enough.
> + 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;
> + }
> +
With removing cma_init_reserved_mem() from API this would move to
__cma_declare_contiguous_nid().
> /*
> * CMA uses CMA_MIN_ALIGNMENT_BYTES as alignment requirement which
> * needs pageblock_order to be initialized. Let's enforce it.
> --
> 2.43.0
>
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2026-10-29 7:42 UTC|newest]
Thread overview: 10+ 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-28 14:03 ` Pratyush Yadav
2026-10-29 7:35 ` Mike Rapoport
2026-10-29 13:11 ` Pratyush Yadav
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
2026-10-28 14:16 ` Pratyush Yadav
2026-10-29 7:42 ` Mike Rapoport [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=auL49EhsNL4jc1o3@kernel.org \
--to=rppt@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=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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=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.