From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 2/5] of: reserved_mem: reject static regions overlapping no-map memory
Date: Tue, 18 Aug 2026 09:40:50 +0000 [thread overview]
Message-ID: <20260818094051.50CD11F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260818092420.2859026-3-chenwandun1@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch provides an incomplete fix for overlapping reservations, allowing a static `map` region to silently overlap an existing `no-map` region.
- [High] Error handling in `__reserved_mem_alloc_size()` ignores the return code, leading to a Use-After-Free of physical memory if marking a dynamic `no-map` region fails.
--
--- Patch [2]: [PATCH v2 2/5] of: reserved_mem: reject static regions overlapping no-map memory ---
commit 5bad18fc3e691089fa21e129bf6cd3d6145676c4
Author: Wandun Chen <chenwandun@lixiang.com>
of: reserved_mem: reject static regions overlapping no-map memory
Static no-map reserved-memory regions are marked in memblock.memory rather
than memblock.reserved. So the reservation overlap check does not reject
a static region that overlaps existing no-map memory. Both regions can then
be initialized and hand the same physical memory to different drivers.
This commit rejects static regions that overlap existing no-map memory.
Link: https://sashiko.dev/#/message/20260814084718.29C341F000E9%40smtp.kernel.org [1]
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 491d64d93d707..f25dc0cca2f06 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -152,7 +152,8 @@ static int __init early_init_dt_reserve_memory(phys_addr_t base,
> * if the region isn't memory as it won't be mapped.
> */
> if (memblock_overlaps_region(&memblock.memory, base, size) &&
> - memblock_is_region_reserved(base, size))
> + (memblock_is_region_reserved(base, size) ||
> + memblock_overlaps_nomap(base, size)))
> return -EBUSY;
>
> return memblock_mark_nomap(base, size);
[Severity: High]
This isn't a bug introduced by this patch, but since this patch is fixing
overlap checks, does the !nomap path still allow a static map region to
silently overlap an existing no-map region?
If a Device Tree contains a no-map region followed by a regular map region
pointing to the same physical address, the no-map region is processed first.
When the map region is processed, nomap is false, so it bypasses the
overlap check updated here and directly calls memblock_reserve():
drivers/of/of_reserved_mem.c:early_init_dt_reserve_memory() {
if (nomap) {
...
return memblock_mark_nomap(base, size);
}
return memblock_reserve(base, size);
}
Since memblock_reserve() adds the region to memblock.reserved without
checking for MEMBLOCK_NOMAP overlaps in memblock.memory, both regions
can be initialized. This would hand the same physical memory to different
reserved-memory drivers.
Should the !nomap path also check for overlaps against existing no-map
memory?
While reviewing the memory allocation paths, I also noticed a pre-existing
issue in __reserved_mem_alloc_size().
[Severity: High]
This is a pre-existing issue, but could this error handling cause a
use-after-free of physical memory if memblock_mark_nomap() fails?
Looking at early_init_dt_alloc_reserved_memory_arch():
drivers/of/of_reserved_mem.c:early_init_dt_alloc_reserved_memory_arch() {
...
base = memblock_phys_alloc_range(size, align, start, end);
if (!base)
return -ENOMEM;
*res_base = base;
if (nomap) {
err = memblock_mark_nomap(base, size);
if (err)
memblock_phys_free(base, size);
}
...
return err;
}
If memblock_mark_nomap() fails, it frees the allocated memory and returns
the error code, but *res_base (the base pointer in the caller) remains
set to the freed address.
In __reserved_mem_alloc_size(), the return code is ignored:
drivers/of/of_reserved_mem.c:__reserved_mem_alloc_size() {
...
ret = early_init_dt_alloc_reserved_memory_arch(size, align,
0, 0, nomap, &base);
if (ret == 0)
pr_debug(...);
if (base == 0) {
pr_err(...);
return -ENOMEM;
}
fdt_init_reserved_mem_node(node, uname, base, size);
...
}
Because __reserved_mem_alloc_size() ignores ret and only checks
if (base == 0), it will proceed with the freed memory and register it via
fdt_init_reserved_mem_node(). The page allocator will hand this memory to
regular allocations while a reserved-memory driver also uses it.
Should this check be if (ret != 0) or if (base == 0 || ret != 0) to
properly catch allocation failures?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260818092420.2859026-1-chenwandun1@gmail.com?part=2
next prev parent reply other threads:[~2026-08-18 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 9:24 [PATCH v2 0/5] of: reserved_mem: several fixes about reserved memory Wandun Chen
2026-08-18 9:24 ` [PATCH v2 1/5] of: reserved_mem: skip init for regions whose early reservation failed Wandun Chen
2026-08-18 9:24 ` [PATCH v2 2/5] of: reserved_mem: reject static regions overlapping no-map memory Wandun Chen
2026-08-18 9:40 ` sashiko-bot [this message]
2026-08-18 9:24 ` [PATCH v2 3/5] of: reserved_mem: reject statically placed regions overlapping existing reservations Wandun Chen
2026-08-18 9:41 ` sashiko-bot
2026-08-18 9:24 ` [PATCH v2 4/5] of: reserved_mem: release dynamically allocated no-map region on init failure Wandun Chen
2026-08-18 9:38 ` sashiko-bot
2026-08-18 9:24 ` [PATCH v2 5/5] of: reserved_mem: retain static no-map memory " Wandun Chen
2026-08-18 9:34 ` sashiko-bot
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=20260818094051.50CD11F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chenwandun1@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.