Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 1/3] of: reserved_mem: avoid unnecessary memory allocation when __reserved_mem_check_root() fails
Date: Tue, 19 May 2026 08:46:46 +0000	[thread overview]
Message-ID: <20260519084646.C9974C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260519082427.4181476-2-chenwandun@lixiang.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Error paths in alloc_reserved_mem_array() fail to reset total_reserved_mem_cnt, causing a deterministic buffer overflow.
--

commit b6927a2d1eca00b0e1f7c1ca6f640812391b20c8
Author: Wandun Chen <chenwandun1@gmail.com>

of: reserved_mem: avoid unnecessary memory allocation when __reserved_mem_check_root() fails

This commit delays the dynamic allocation of the reserved memory array
until after checking the root node format. It aims to prevent memory
allocation and potential waste if the reserved memory root format is
unsupported.

> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -265,14 +265,14 @@ void __init fdt_scan_reserved_mem_late(void)
[ ... ]
>  	if (__reserved_mem_check_root(node)) {
>  		pr_err("Reserved memory: unsupported node format, ignoring\n");
>  		return;
>  	}
>  
> +	/* Attempt dynamic allocation of a new reserved_mem array */
> +	alloc_reserved_mem_array();

This isn't a bug introduced by this commit, but while looking at the
relocation of alloc_reserved_mem_array(), I noticed a pre-existing flaw
in its error paths.

If total_reserved_mem_cnt exceeds MAX_RESERVED_REGIONS (64), we attempt
to allocate a new array. If memblock_alloc() fails or alloc_size == SIZE_MAX,
alloc_reserved_mem_array() logs an error and returns early without resetting
total_reserved_mem_cnt back to MAX_RESERVED_REGIONS.

Since alloc_reserved_mem_array() returns void and doesn't propagate the
error, fdt_scan_reserved_mem_late() continues iterating over the remaining
nodes and calling fdt_init_reserved_mem_node().

Does this lead to an out-of-bounds write?

In fdt_init_reserved_mem_node(), the bounds check compares against the active
total_reserved_mem_cnt:

drivers/of/of_reserved_mem.c:fdt_init_reserved_mem_node() {
    ...
    if (reserved_mem_count == total_reserved_mem_cnt) {
        pr_err("not enough space for all defined regions.\n");
        return -ENOSPC;
    }
    ...
}

If alloc_reserved_mem_array() failed, reserved_mem still points to the
static 64-element array, but total_reserved_mem_cnt is still set to the
larger requested size. This appears to allow reserved_mem_count to exceed
64, deterministically writing past the end of the static array.

Could the error paths in alloc_reserved_mem_array() be updated to always
reset total_reserved_mem_cnt to MAX_RESERVED_REGIONS?

> +
>  	fdt_for_each_subnode(child, fdt, node) {
>  		const char *uname;
>  		u64 b, s;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519082427.4181476-1-chenwandun@lixiang.com?part=1

  reply	other threads:[~2026-05-19  8:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  8:24 [PATCH v2 0/3] of: reserved_mem: fixes and cleanups Wandun Chen
2026-05-19  8:24 ` [PATCH v2 1/3] of: reserved_mem: avoid unnecessary memory allocation when __reserved_mem_check_root() fails Wandun Chen
2026-05-19  8:46   ` sashiko-bot [this message]
2026-05-19  8:24 ` [PATCH v2 2/3] of: reserved_mem: clean up redundant alloc_reserved_mem_array() call Wandun Chen
2026-05-19  9:09   ` sashiko-bot
2026-05-19  8:24 ` [PATCH v2 3/3] of: reserved_mem: only support one <base size> entry in reg property Wandun Chen
2026-05-19  9:24   ` 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=20260519084646.C9974C2BCB3@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox