From: sashiko-bot@kernel.org
To: "Fuad Tabba" <fuad.tabba@linux.dev>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH] of/irq: Fix device node refcount leak in of_irq_get_affinity()
Date: Wed, 26 Aug 2026 11:36:03 +0000 [thread overview]
Message-ID: <20260826113604.010C01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826112234.1033974-1-fuad.tabba@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Device node reference count leak when resolving MSI domain RID via 'msi-parent' fallback.
- [High] Pre-existing memory leak of device node reference in `gic_irq_get_fwspec_info`.
--
commit 105954fbf27e6537ca0c4da266eb89a3c31643fd
Author: Fuad Tabba <fuad.tabba@linux.dev>
of/irq: Fix device node refcount leak in of_irq_get_affinity()
This commit fixes a device node reference count leak in of_irq_get_affinity().
The of_irq_parse_one() call raises the refcount of the interrupt controller
node on success, and of_irq_get_affinity() returns without putting it. The
fix drops the reference once irq_populate_fwspec_info() has run.
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 967c191008797..ec035367c9500 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -563,7 +563,9 @@ const struct cpumask *of_irq_get_affinity(struct device_node *dev, int index)
> of_phandle_args_to_fwspec(oirq.np, oirq.args, oirq.args_count,
> &fwspec);
>
> - if (irq_populate_fwspec_info(&fwspec, &info))
> + rc = irq_populate_fwspec_info(&fwspec, &info);
> + of_node_put(oirq.np);
> + if (rc)
> return NULL;
>
> return info.affinity;
[Severity: High]
This isn't a bug introduced by this patch, but there appears to be a
device node reference count leak when resolving MSI domain RID via
msi-parent fallback.
drivers/pci/msi/irqdomain.c:pci_msi_domain_get_msi_rid()
> of_node = irq_domain_get_of_node(domain);
> rid = of_node ? of_msi_xlate(&pdev->dev, &of_node, rid) :
> iort_msi_map_id(&pdev->dev, rid);
>
> return rid;
If the mapping falls back to msi-parent in of_msi_xlate(), the
un-refcounted of_node pointer is overwritten with a newly refcounted
pointer in of_check_msi_parent():
drivers/of/irq.c:of_check_msi_parent()
> if (!ret) {
> /* Return with a node reference held */
> *msi_node = msi_spec.np;
> return 0;
> }
Since pci_msi_domain_get_msi_rid() returns the mapped RID without calling
of_node_put() on the updated of_node, does this leak the MSI controller
device node on every invocation?
[Severity: High]
This is a pre-existing issue, but is there also a memory leak of the
device node reference in gic_irq_get_fwspec_info()?
drivers/irqchip/irq-gic-v3.c:gic_irq_get_fwspec_info()
> fw = of_fwnode_handle(of_find_node_by_phandle(fwspec->param[3]));
> if (!fw)
> return -ENOENT;
>
> for (int i = 0; i < gic_data.nr_parts; i++) {
> if (gic_data.parts[i].partition_id == fw) {
> mask = &gic_data.parts[i].mask;
> break;
> }
> }
>
> if (!mask)
> return -ENOENT;
> } else {
> mask = cpu_possible_mask;
> }
>
> info->affinity = mask;
> info->flags = IRQ_FWSPEC_INFO_AFFINITY_VALID;
>
> return 0;
The call to of_find_node_by_phandle() acquires a new reference on the
device node, but the function returns on various error and success paths
without calling of_node_put() to drop it. Does this leak the GIC PPI
partition device nodes during IRQ affinity retrieval?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826112234.1033974-1-fuad.tabba@linux.dev?part=1
next prev parent reply other threads:[~2026-08-26 11:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 11:22 [PATCH] of/irq: Fix device node refcount leak in of_irq_get_affinity() Fuad Tabba
2026-08-26 11:36 ` sashiko-bot [this message]
2026-08-26 12:19 ` Fuad Tabba
2026-08-26 14:49 ` Rob Herring (Arm)
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=20260826113604.010C01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fuad.tabba@linux.dev \
--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.