From: sashiko-bot@kernel.org
To: "Ryan Chen" <ryan_chen@aspeedtech.com>
Cc: robh@kernel.org, conor+dt@kernel.org,
linux-rt-devel@lists.linux.dev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] EDAC/aspeed: Free the mem_ctl_info unconditionally on remove
Date: Wed, 12 Aug 2026 05:57:38 +0000 [thread overview]
Message-ID: <20260812055739.2C7691F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-edac-v1-4-03992edea297@aspeedtech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential use-after-free of `mci` in the interrupt handler during driver removal due to devm-managed IRQ and manual resource freeing.
--
--- Patch [4]: [PATCH 4/7] EDAC/aspeed: Free the mem_ctl_info unconditionally on remove ---
commit c5d400d5b360781ecdef9cf321a50a2fde1b94dc
Author: Ryan Chen <ryan_chen@aspeedtech.com>
EDAC/aspeed: Free the mem_ctl_info unconditionally on remove
This commit removes a redundant NULL check on the return value of
edac_mc_del_mc() in aspeed_remove(), instead fetching the mem_ctl_info
from driver data to free it unconditionally.
> diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
> index 71535e0b6bad8..8bfeb21d3204a 100644
> --- a/drivers/edac/aspeed_edac.c
> +++ b/drivers/edac/aspeed_edac.c
> @@ -343,16 +343,15 @@ static int aspeed_probe(struct platform_device *pdev)
>
> static void aspeed_remove(struct platform_device *pdev)
> {
> - struct mem_ctl_info *mci;
> + struct mem_ctl_info *mci = platform_get_drvdata(pdev);
>
> /* disable interrupts */
> regmap_update_bits(aspeed_regmap, ASPEED_MCR_INTR_CTRL,
> ASPEED_MCR_INTR_CTRL_ENABLE, 0);
>
> /* free resources */
> - mci = edac_mc_del_mc(&pdev->dev);
> - if (mci)
> - edac_mc_free(mci);
> + edac_mc_del_mc(&pdev->dev);
> + edac_mc_free(mci);
[Severity: High]
This is a pre-existing issue, but could this edac_mc_free() cause a
use-after-free if the interrupt handler is running concurrently during
driver removal?
Because config_irq() registers the interrupt using devm_request_irq(), the
IRQ handler won't be unregistered and synchronized until devres cleanup
runs, which happens after aspeed_remove() returns.
While the hardware interrupt is disabled via regmap_update_bits() just
above, this does not wait for already-executing handlers on other CPUs
to finish. If mcr_isr() is running on another CPU, it could access the
just-freed mci:
mcr_isr() {
struct mem_ctl_info *mci = arg;
...
dev_dbg(mci->pdev, "received edac interrupt...");
}
Would it be safer to explicitly free and synchronize the interrupt before
freeing mci, or use a non-devm request_irq()/free_irq() instead?
> }
>
> static const struct of_device_id aspeed_of_match[] = {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-edac-v1-0-03992edea297@aspeedtech.com?part=4
next prev parent reply other threads:[~2026-08-12 5:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 5:48 [PATCH 0/7] Add Aspeed AST2700 SDRAM EDAC support Ryan Chen
2026-08-12 5:48 ` [PATCH 1/7] dt-bindings: edac: aspeed: Add AST2700 SDRAM EDAC Ryan Chen
2026-08-12 5:48 ` [PATCH 2/7] EDAC/aspeed: Set the DIMM grain Ryan Chen
2026-08-12 5:48 ` [PATCH 3/7] EDAC/aspeed: Clean up whitespace and include ordering Ryan Chen
2026-08-12 5:48 ` [PATCH 4/7] EDAC/aspeed: Free the mem_ctl_info unconditionally on remove Ryan Chen
2026-08-12 5:57 ` sashiko-bot [this message]
2026-08-12 5:48 ` [PATCH 5/7] EDAC/aspeed: Replace regmap with direct register access Ryan Chen
2026-08-12 6:03 ` sashiko-bot
2026-08-12 5:48 ` [PATCH 6/7] EDAC/aspeed: Abstract SoC differences behind chip data Ryan Chen
2026-08-12 6:01 ` sashiko-bot
2026-08-12 5:48 ` [PATCH 7/7] EDAC/aspeed: Add AST2700 support Ryan Chen
2026-08-12 6:00 ` 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=20260812055739.2C7691F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=robh@kernel.org \
--cc=ryan_chen@aspeedtech.com \
--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.