From: sashiko-bot@kernel.org
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
wsa+renesas@sang-engineering.com, krzk+dt@kernel.org,
linux-watchdog@vger.kernel.org, robh@kernel.org
Subject: Re: [RFC PATCH 2/9] clk: renesas: r9a09g077: Add SYSC regmap support
Date: Wed, 13 May 2026 00:12:51 +0000 [thread overview]
Message-ID: <20260513001252.12A99C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511185058.1926869-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Use-After-Free vulnerability due to globally registering a devres-managed regmap.
- [Medium] Memory leak of devres allocations for non-matching child nodes during initialization.
--
commit 42e8a93f573528685964e7e4e8583fa90ffb5b6b
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
clk: renesas: r9a09g077: Add SYSC regmap support
This commit adds System Controller (SYSC) regmap support for the RZ/T2H SoC.
It implements support for creating regmaps for SYSC blocks defined as
child nodes within the CPG address space, and registers them using
of_syscon_register_regmap().
> diff --git a/drivers/clk/renesas/r9a09g077-cpg.c b/drivers/clk/renesas/r9a09g077-cpg.c
> --- a/drivers/clk/renesas/r9a09g077-cpg.c
> +++ b/drivers/clk/renesas/r9a09g077-cpg.c
[ ... ]
> @@ -514,6 +514,172 @@ r9a09g077_cpg_clk_register(struct device *dev, const struct cpg_core_clk *core,
[ ... ]
> +static int r9a09g077_sysc_init(struct device *dev)
> +{
> + struct device_node *child, *np = dev->of_node;
> +
> + for_each_child_of_node(np, child) {
> + struct regmap_config *regmap_cfg __free(kfree) = kzalloc_obj(*regmap_cfg);
> + struct r9a09g077_sysc_reg *sysc_reg;
> + struct regmap *regmap;
> + void __iomem *base;
> + char *name;
> + u32 index;
> + int ret;
> +
> + sysc_reg = devm_kzalloc(dev, sizeof(*sysc_reg), GFP_KERNEL);
> + if (!sysc_reg) {
> + of_node_put(child);
> + return -ENOMEM;
> + }
> +
> + if (!regmap_cfg) {
> + of_node_put(child);
> + return -ENOMEM;
> + }
> +
> + if (!of_node_name_eq(child, "system-controller"))
> + continue;
Does this leak devm-allocated memory for every child node that isn't named
system-controller?
The devm_kzalloc() call binds the memory to the parent device's lifetime,
not the loop scope. When the loop skips a non-matching node via continue,
the sysc_reg allocation remains until the device is removed.
Could the of_node_name_eq() check be moved above the memory allocations?
[ ... ]
> + regmap = devm_regmap_init(dev, &rzt2h_sys_regmap_bus, sysc_reg, regmap_cfg);
> + if (IS_ERR(regmap)) {
> + of_node_put(child);
> + return PTR_ERR(regmap);
> + }
> +
> + ret = of_syscon_register_regmap(child, regmap);
> + if (ret) {
> + of_node_put(child);
> + return ret;
> + }
> + }
Can this sequence cause a use-after-free if device initialization fails later?
The of_syscon_register_regmap() function adds the regmap to a global
syscon_list, but there is no corresponding unregister function to remove it.
If a subsequent step in the probe path fails, such as of_clk_add_provider()
failing in cpg_mssr_common_init(), the driver core will tear down all
device-managed resources. This will free the regmap and unmap its I/O memory.
Because the freed regmap remains in the global syscon_list, a subsequent
syscon_node_to_regmap() lookup by a consumer would return a dangling pointer,
leading to a use-after-free and a potential MMIO page fault.
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511185058.1926869-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2
next prev parent reply other threads:[~2026-05-13 0:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 18:50 [RFC PATCH 0/9] Add System Controller support for RZ/T2H and RZ/N2H SoCs Prabhakar
2026-05-11 18:50 ` [RFC PATCH 1/9] dt-bindings: clock: renesas,cpg-mssr: Support RZ/T2H system controllers Prabhakar
2026-05-12 22:48 ` sashiko-bot
2026-05-11 18:50 ` [RFC PATCH 2/9] clk: renesas: r9a09g077: Add SYSC regmap support Prabhakar
2026-05-13 0:12 ` sashiko-bot [this message]
2026-05-11 18:50 ` [RFC PATCH 3/9] arm64: dts: renesas: r9a09g077: Add system controller child nodes Prabhakar
2026-05-11 18:50 ` [RFC PATCH 4/9] arm64: dts: renesas: r9a09g087: " Prabhakar
2026-05-11 18:50 ` [RFC PATCH 5/9] dt-bindings: watchdog: renesas,r9a09g057-wdt: Add SYS syscon support Prabhakar
2026-05-13 1:44 ` sashiko-bot
2026-05-11 18:50 ` [RFC PATCH 6/9] watchdog: rzv2h: Refactor WDTDCR start/stop handling Prabhakar
2026-05-11 18:50 ` [RFC PATCH 7/9] watchdog: rzv2h: Add syscon support for RZ/T2H and RZ/N2H WDT control register Prabhakar
2026-05-13 2:27 ` sashiko-bot
2026-05-11 18:50 ` [RFC PATCH 8/9] arm64: dts: renesas: r9a09g077: Use SYS syscon for WDTDCR access Prabhakar
2026-05-13 2:55 ` sashiko-bot
2026-05-11 18:50 ` [RFC PATCH 9/9] arm64: dts: renesas: r9a09g087: " Prabhakar
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=20260513001252.12A99C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=prabhakar.csengg@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.com \
/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