All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Claudiu Beznea" <claudiu.beznea+renesas@tuxon.dev>
Cc: robh@kernel.org, "Oliver Hartkopp" <socketcan@hartkopp.net>,
	conor+dt@kernel.org, "Oleksij Rempel" <o.rempel@pengutronix.de>,
	devicetree@vger.kernel.org,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	linux-can@vger.kernel.org, "Vincent Mailhol" <mailhol@kernel.org>,
	wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v4 5/7] can: rcar_canfd: Add support for Renesas RZ/G3S
Date: Wed, 02 Sep 2026 14:30:13 +0000	[thread overview]
Message-ID: <20260902143013.D70171F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260902141544.565763-6-claudiu.beznea+renesas@tuxon.dev>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Lack of validation for Classical CAN mode on CAN FD-only hardware.

Pre-existing issues:
- [High] Dangling pointer in global array leads to double free when register_candev fails.
--

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

can: rcar_canfd: Add support for Renesas RZ/G3S

This commit adds support for the Renesas RZ/G3S CAN-FD controller.
The RZ/G3S controller supports two channels, 16 AFL pages, and operates
exclusively in CAN-FD mode.

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index bed7cde1aa01b..48e0573a73a44 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
[ ... ]
> @@ -661,6 +661,26 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = {
>  	.fixed_canfd = 0,
>  };
>  
> +static const struct rcar_canfd_hw_info r9a08g045_hw_info = {
> +	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
> +	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
> +	.tdc_const = &rcar_canfd_gen4_tdc_const,
> +	.regs = &rcar_gen4_regs,
> +	.sh = &rcar_gen4_shift_data,
> +	.rnc_field_width = 16,
> +	.max_aflpn = 15,
> +	.max_cftml = 31,
> +	.max_channels = 2,
> +	.postdiv = 2,
> +	.shared_global_irqs = 0,
> +	.multi_channel_irqs = 1,
> +	.ch_interface_mode = 1,
> +	.shared_can_regs = 1,
> +	.external_clk = 1,
> +	.fcan_pclk = 1,
> +	.fixed_canfd = 1,

[Severity: High]
If the device tree specifies the "renesas,no-can-fd" property, could this
lead to a silent mismatch between the software network stack configuration
and the hardware state?

In drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_probe(), if the property is
present, the driver will set fdmode = false:

	if (of_property_read_bool(dev->of_node, "renesas,no-can-fd"))
		fdmode = false;

However, when rcar_canfd_configure_controller() runs, it skips the
controller mode update because fixed_canfd is true:

	if (gpriv->info->fixed_canfd)
		continue;

This effectively leaves the hardware locked in CAN FD mode, while the rest of
the driver initializes the software stack for Classical CAN. For example,
rcar_canfd_channel_probe() initializes a max MTU of 16 bytes, and
rcar_canfd_configure_rx() restricts the physical hardware Rx FIFO payload
size to 8 bytes.

If the hardware receives a 64-byte CAN FD frame, will it attempt to write
64 bytes into an Rx FIFO configured for 8 bytes, causing a buffer overflow?

> +};
> +
[ ... ]
> @@ -2383,6 +2403,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_canfd_pm_ops, rcar_canfd_suspend,
>  
>  static const __maybe_unused struct of_device_id rcar_canfd_of_table[] = {
>  	{ .compatible = "renesas,r8a779a0-canfd", .data = &rcar_gen4_hw_info },
> +	{ .compatible = "renesas,r9a08g045-canfd", .data = &r9a08g045_hw_info },

[Severity: High]
This is a pre-existing issue, but does probe failure on this newly added
hardware expose a potential double-free?

In drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_channel_probe(), the global
array is populated before device registration:

	gpriv->ch[priv->channel] = priv;
	...
	err = register_candev(ndev);
	if (err) {
		...
		goto fail_candev;
	}

If register_candev() fails, the error path calls free_candev(ndev), which
also frees the embedded priv structure, but leaves the dangling pointer in
gpriv->ch[priv->channel].

When the failure propagates back to rcar_canfd_probe(), the cleanup block
iterates over all configured channels and calls rcar_canfd_channel_remove()
for each, including the one that just failed:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_channel_remove() {
	...
	unregister_candev(priv->ndev);
	...
	free_candev(priv->ndev);
}

Could this lead to memory corruption when it attempts to unregister and free
the already freed dangling pointer?

>  	{ .compatible = "renesas,r9a09g047-canfd", .data = &r9a09g047_hw_info },
>  	{ .compatible = "renesas,r9a09g077-canfd", .data = &r9a09g077_hw_info },
>  	{ .compatible = "renesas,rcar-gen3-canfd", .data = &rcar_gen3_hw_info },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902141544.565763-1-claudiu.beznea+renesas@tuxon.dev?part=5

  reply	other threads:[~2026-09-02 14:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 14:15 [PATCH v4 0/7] can: rcar_canfd: Add support for Renesas RZ/G3S Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 1/7] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 2/7] can: rcar_canfd: Fix typos in macro names Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 3/7] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 4/7] can: rcar_canfd: Do not set registers selecting the CAN mode Claudiu Beznea
2026-09-02 14:29   ` sashiko-bot
2026-09-07 12:37     ` Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 5/7] can: rcar_canfd: Add support for Renesas RZ/G3S Claudiu Beznea
2026-09-02 14:30   ` sashiko-bot [this message]
2026-09-07 12:32     ` Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 6/7] arm64: dts: renesas: r9a08g045: Add CAN-FD node Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 7/7] arm64: dts: renesas: rzg3s-smarc: Enable CAN-FD Claudiu Beznea

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=20260902143013.D70171F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=claudiu.beznea+renesas@tuxon.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=o.rempel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    --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 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.