Devicetree
 help / color / mirror / Atom feed
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

  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