Linux CAN drivers development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	linux-can@vger.kernel.org,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Vincent Mailhol" <mailhol@kernel.org>
Subject: Re: [PATCH] can: convert unreliable ARPHRD_CAN type checks to robust can_get_ml_priv()
Date: Wed, 19 Aug 2026 16:26:08 +0000	[thread overview]
Message-ID: <20260819162609.2EF0E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819160822.8256-1-socketcan@hartkopp.net>

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

Pre-existing issues:
- [High] Data modification of shared/cloned SKBs in `can_send()` causes payload corruption for concurrent users.
--

--- Patch [1]: [PATCH] can: convert unreliable ARPHRD_CAN type checks to robust can_get_ml_priv() ---
commit 57320b2cc995d1852816aaacf79460f42c05858d
Author: Oliver Hartkopp <socketcan@hartkopp.net>

can: convert unreliable ARPHRD_CAN type checks to robust can_get_ml_priv()

This commit updates the CAN subsystem to use can_get_ml_priv() for
identifying valid CAN devices instead of relying on ARPHRD_CAN. This
prevents issues with TUN/TAP devices that might overwrite their hardware
type without properly initializing the midlayer private data.

Cc: stable@kernel.org
Cc: Oleksij Rempel <o.rempel@pengutronix.de>

> diff --git a/net/can/af_can.c b/net/can/af_can.c
> index 7bc86b176b4de..ef435f22ac933 100644
> --- a/net/can/af_can.c
> +++ b/net/can/af_can.c
> @@ -226,7 +226,7 @@ int can_send(struct sk_buff *skb, int loop)
>  		goto inval_skb;
>  	}
>  

[Severity: High]
This is a pre-existing issue, but can modifying the SKB payload here cause
data corruption for concurrent receivers?

Earlier in can_send(), the SKB data is directly modified without checking if
it is shared:

	} else if (can_is_canfd_skb(skb)) {
		struct canfd_frame *cfd = (struct canfd_frame *)skb->data;

		skb->protocol = htons(ETH_P_CANFD);

		/* set CAN FD flag for CAN FD frames by default */
		cfd->flags |= CANFD_FDF;

When routing frames without data modifications, can_can_gw_rcv() creates
a cloned SKB using skb_clone() and passes it to can_send():

net/can/gw.c:can_can_gw_rcv() {
	...
	nskb = skb_clone(skb, GFP_ATOMIC);
	...
	can_send(nskb, gwj->limit_hops);
}

Since skb_clone() shares the underlying data buffer, wouldn't modifying
cfd->flags directly in can_send() corrupt the payload for other concurrent
users of the original SKB?

> -	if (unlikely(skb->dev->type != ARPHRD_CAN)) {
> +	if (unlikely(!can_get_ml_priv(skb->dev))) {
>  		err = -EPERM;
>  		goto inval_skb;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819160822.8256-1-socketcan@hartkopp.net?part=1

  reply	other threads:[~2026-08-19 16:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 16:08 [PATCH] can: convert unreliable ARPHRD_CAN type checks to robust can_get_ml_priv() Oliver Hartkopp
2026-08-19 16:26 ` sashiko-bot [this message]
2026-08-19 17:05   ` Oliver Hartkopp
2026-08-25 14:55 ` Oliver Hartkopp
2026-08-26 11:43   ` Marc Kleine-Budde
2026-08-26 19:34     ` Oliver Hartkopp
2026-08-27  6:22       ` Sebastian Andrzej Siewior

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=20260819162609.2EF0E1F000E9@smtp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox