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: 9+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox