[PATCH 0/2] ARM: mstar: fix two device_node refcount leaks in mstarv7.c

[PATCH 0/2] ARM: mstar: fix two device_node refcount leaks in mstarv7.c

[Weigang He]

mstarv7.c leaks the device_node reference taken by
of_find_compatible_node() in two __init paths: mstarv7_boot_secondary()
(the "mstar,smpctrl" node) and mstarv7_init() (the "mstar,l3bridge"
node). of_iomap() does not take ownership of the node, so each is a
one-shot device_node refcount leak per boot.

The two leaks were introduced by different commits, so they are split
into one patch each. Both drop the reference right after of_iomap().

Found by static analysis tool CodeQL. The series is build-tested only
(arm, multi_v7_defconfig + CONFIG_ARCH_MSTARV7); I have no mstar
hardware, so runtime testing would be appreciated.

Weigang He (2):
  ARM: mstar: fix device_node refcount leak in mstarv7_boot_secondary()
  ARM: mstar: fix device_node refcount leak in mstarv7_init()

 arch/arm/mach-mstar/mstarv7.c | 2 ++
 1 file changed, 2 insertions(+)


base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
-- 
2.43.0

[PATCH 1/2] ARM: mstar: fix device_node refcount leak in mstarv7_boot_secondary()

[Weigang He]

of_find_compatible_node() returns a device_node with its refcount
incremented; the caller must drop it with of_node_put() when done.
mstarv7_boot_secondary() obtains the "mstar,smpctrl" node, maps it with
of_iomap() and never releases the reference, leaking it on both the
-ENODEV error path and the success path.

mstar SoCs do not support CPU hot-unplug (mstarv7_smp_ops provides no
.cpu_die), so this leaks one refcount on the smpctrl node once per boot
when the secondary CPU is brought up.

Drop the reference right after of_iomap(), since np is not used
afterwards.

Found by static analysis tool CodeQL.

Fixes: 5919eec0f092 ("ARM: mstar: SMP support")
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
---
 arch/arm/mach-mstar/mstarv7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mstar/mstarv7.c b/arch/arm/mach-mstar/mstarv7.c
index 274c4f0df270f..871c0fd258e66 100644
--- a/arch/arm/mach-mstar/mstarv7.c
+++ b/arch/arm/mach-mstar/mstarv7.c
@@ -86,6 +86,7 @@ static int mstarv7_boot_secondary(unsigned int cpu, struct task_struct *idle)
 
 	np = of_find_compatible_node(NULL, NULL, "mstar,smpctrl");
 	smpctrl = of_iomap(np, 0);
+	of_node_put(np);
 
 	if (!smpctrl)
 		return -ENODEV;
-- 
2.43.0

[PATCH 2/2] ARM: mstar: fix device_node refcount leak in mstarv7_init()

[Weigang He]

of_find_compatible_node() returns a device_node with its refcount
incremented; the caller must drop it with of_node_put() when done.
mstarv7_init() obtains the "mstar,l3bridge" node, maps it with
of_iomap() and never releases the reference, leaking it.

mstarv7_init() is the __init machine init callback, so this leaks one
refcount on the l3bridge node once per boot for the lifetime of the
system.

Drop the reference right after of_iomap(), since np is not used
afterwards.

Found by static analysis tool CodeQL.

Fixes: 312b62b6610c ("ARM: mstar: Add machine for MStar/Sigmastar Armv7 SoCs")
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
---
 arch/arm/mach-mstar/mstarv7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mstar/mstarv7.c b/arch/arm/mach-mstar/mstarv7.c
index 871c0fd258e66..64262b8f10a0c 100644
--- a/arch/arm/mach-mstar/mstarv7.c
+++ b/arch/arm/mach-mstar/mstarv7.c
@@ -117,6 +117,7 @@ static void __init mstarv7_init(void)
 
 	np = of_find_compatible_node(NULL, NULL, "mstar,l3bridge");
 	l3bridge = of_iomap(np, 0);
+	of_node_put(np);
 	if (l3bridge)
 		soc_mb = mstarv7_mb;
 	else
-- 
2.43.0

Re: [PATCH 0/2] ARM: mstar: fix two device_node refcount leaks in mstarv7.c

[Daniel Palmer]

Hi Weigang,

On Wed, 10 Jun 2026 at 14:33, Weigang He <geoffreyhe2@gmail.com> wrote:
> Found by static analysis tool CodeQL. The series is build-tested only
> (arm, multi_v7_defconfig + CONFIG_ARCH_MSTARV7); I have no mstar
> hardware, so runtime testing would be appreciated.

I can build and boot test this but as far as I'm aware this is non-issue?
I have one device running this code stuck under a desk that has an
uptime over 3+ years now I think.

I guess maybe merge them just to stop another person from sending
another version of this?

Cheers,

Daniel