All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Vincent Mailhol" <mailhol@kernel.org>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH net-next 03/12] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck
Date: Wed, 11 Nov 2026 11:51:33 +0000	[thread overview]
Message-ID: <sashiko-outbox-208905@kernel.org> (raw)
In-Reply-To: <20261110115112.3807247-4-mkl@pengutronix.de>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] can: rcar_canfd: use-after-free in
  rcar_canfd_channel_remove() [1]
--

commit 1df4cf4f9a1348dd6433254810179fc111ec5e51
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

This commit adds a struct rcar_canfd_hw_info flag to allow sourcing the
CAN FD clock from the peripheral clock (fck) on Renesas RZ/G3S.

Link: https://lore.kernel.org/all/1d9719e3-10ff-4cd8-b729-55fea93c37ce@wanadoo.fr
Link: https://patch.msgid.link/20260902141544.565763-4-claudiu.beznea+renesas@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index b7c4fe3477ac5..f9173774387fa 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c

[ ... ]

> @@ -2190,13 +2196,20 @@ static int rcar_canfd_probe(struct platform_device *pdev)
>  	 */
>  	gpriv->can_clk = devm_clk_get(dev, "can_clk");
>  	if (IS_ERR(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {
> -		gpriv->can_clk = devm_clk_get(dev, "canfd");
> -		if (IS_ERR(gpriv->can_clk))
> -			return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> -					     "cannot get canfd clock\n");
> +		if (info->fcan_pclk) {
> +			fcan_freq = clk_get_rate(gpriv->clkp);
> +			gpriv->can_clk = NULL;
> +		} else {
> +			gpriv->can_clk = devm_clk_get(dev, "canfd");
> +			if (IS_ERR(gpriv->can_clk))
> +				return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> +						     "cannot get canfd clock\n");
> +
> +			fcan_freq = clk_get_rate(gpriv->can_clk);
> +		}
>  
>  		/* CANFD clock may be further divided within the IP */
> -		fcan_freq = clk_get_rate(gpriv->can_clk) / info->postdiv;
> +		fcan_freq /= info->postdiv;
>  	} else {
>  		fcan_freq = clk_get_rate(gpriv->can_clk);
>  		gpriv->extclk = gpriv->info->external_clk;

[Severity: Critical]
This problem wasn't introduced by this patch, but can a failure in
rcar_canfd_channel_probe() lead to a use-after-free and double free of ndev
[1] during fail_channel cleanup in rcar_canfd_probe()?

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_channel_probe() {
    ...
	gpriv->ch[priv->channel] = priv;
	err = register_candev(ndev);
	if (err) {
		dev_err(dev, "register_candev() failed: %pe\n", ERR_PTR(err));
		goto fail_candev;
	}
    ...
fail_candev:
	netif_napi_del(&priv->napi);
fail:
	free_candev(ndev);
	return err;
}

When register_candev() fails, rcar_canfd_channel_probe() frees ndev (which
contains priv) without clearing gpriv->ch[priv->channel].  rcar_canfd_probe()
then jumps to fail_channel and calls rcar_canfd_channel_remove(), which sees
the dangling gpriv->ch[ch] pointer and passes priv->ndev to
unregister_candev() and free_candev() a second time.

[1] https://sashiko.dev/#/bug/linux-5ba990d8-8cef-4735-85ff-107958a3daf2

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=3

  reply	other threads:[~2026-11-11 11:51 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 11:41 [PATCH net-next 0/12] pull-request: can-next 2026-11-10 Marc Kleine-Budde
2026-11-10 11:41 ` [PATCH net-next 01/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-12 18:30   ` patchwork-bot+netdevbpf
2026-11-10 11:41 ` [PATCH net-next 02/12] can: rcar_canfd: Fix typos in macro names Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot
2026-11-10 11:41 ` [PATCH net-next 03/12] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot [this message]
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 04/12] can: rcar_canfd: Do not set registers selecting the CAN mode Marc Kleine-Budde
2026-11-10 11:41 ` [PATCH net-next 05/12] can: rcar_canfd: Add support for Renesas RZ/G3S Marc Kleine-Budde
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 06/12] can: rcar_canfd: Check can_clk request for errors Marc Kleine-Budde
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot
2026-11-11 12:01   ` Marc Kleine-Budde
2026-11-12 12:25     ` Marc Kleine-Budde
2026-11-12 13:39     ` claudiu beznea
2026-11-12 13:44       ` Marc Kleine-Budde
2026-11-12 18:20         ` Jakub Kicinski
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 08/12] dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 09/12] dt-bindings: can: renesas,rcar-canfd: Simplify renesas,no-can-fd description Marc Kleine-Budde
2026-11-10 11:41 ` [PATCH net-next 10/12] can: rcar_canfd: Document that RZ/G3S has no Classical CAN mode Marc Kleine-Budde
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 11/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC Marc Kleine-Budde
2026-11-11 11:51   ` sashiko-bot
2026-11-11 12:20   ` netdev-bot+sashiko
2026-11-10 11:41 ` [PATCH net-next 12/12] can: rcar_canfd: Add support for Renesas RZ/G3L Marc Kleine-Budde

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=sashiko-outbox-208905@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=o.rempel@pengutronix.de \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    /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.