All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Vincent Mailhol" <mailhol@kernel.org>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	linux-can@vger.kernel.org,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>
Subject: Re: [PATCH v4 7/7] can: bcm: validate frame length in bcm_rx_setup() for RTR replies
Date: Tue, 07 Jul 2026 14:51:34 +0000	[thread overview]
Message-ID: <20260707145135.5BC831F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260707-bcm_fixes-v4-7-aa87b8b9d33f@hartkopp.net>

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

Pre-existing issues:
- [High] Data race on `op->rx_ifindex` and `op->rx_stamp` in `bcm_rx_handler` leading to incorrect metadata being reported to userspace.
--

--- Patch [7]: [PATCH v4 7/7] can: bcm: validate frame length in bcm_rx_setup() for RTR replies ---
commit 1023235e0f18b95b00bedbafd97f5943d8506566
Author: Oliver Hartkopp <socketcan@hartkopp.net>

can: bcm: validate frame length in bcm_rx_setup() for RTR replies

This commit fixes a missing frame length check in bcm_rx_setup() for
RTR-reply frames configured via RX_SETUP with RX_RTR_FRAME. It ensures
cf->len is validated against CAN and CAN FD limits before installation.

> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index f04216723e0fc..d4d2c89dc4009 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c
[ ... ]
> @@ -1467,6 +1482,14 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
>  	}
>  
>  	return msg_head->nframes * op->cfsiz + MHSIZ;
> +
> +free_op:
> +	if (op->frames != &op->sframe)
> +		kfree(op->frames);
> +	if (op->last_frames != &op->last_sframe)
> +		kfree(op->last_frames);
> +	kfree(op);
> +	return err;
>  }

[Severity: High]
This is a pre-existing issue, but I noticed a potential data race in
bcm_rx_handler() involving op->rx_ifindex and op->rx_stamp.

When a user creates a BCM socket listening on all interfaces (ifindex=0),
and CAN frames matching the filter arrive concurrently on multiple
interfaces (e.g., handled by different CPUs in softirq), bcm_rx_handler()
can execute concurrently. Both CPUs appear to write to op->rx_stamp and
op->rx_ifindex without synchronization before acquiring 
op->bcm_rx_update_lock:

net/can/bcm.c:bcm_rx_handler() {
	...
	op->rx_stamp = skb->tstamp;
	/* save originator for recvfrom() */
	op->rx_ifindex = skb->dev->ifindex;
	...
}

Later, bcm_send_to_user() reads these fields to send metadata to userspace:

net/can/bcm.c:bcm_send_to_user() {
	...
	skb->tstamp = op->rx_stamp;
	...
	addr = (struct sockaddr_can *)skb->cb;
	memset(addr, 0, sizeof(*addr));
	addr->can_family  = AF_CAN;
	addr->can_ifindex = op->rx_ifindex;
	...
}

Could this lead to torn reads of the 64-bit rx_stamp on 32-bit platforms
and incorrect rx_ifindex values being reported to userspace?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-bcm_fixes-v4-0-aa87b8b9d33f@hartkopp.net?part=7

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

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 14:32 [PATCH v4 0/7] can: bcm: collected fixes Oliver Hartkopp
2026-07-07 14:32 ` Oliver Hartkopp via B4 Relay
2026-07-07 14:32 ` [PATCH v4 1/7] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:47   ` sashiko-bot
2026-07-07 14:32 ` [PATCH v4 2/7] can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:53   ` sashiko-bot
2026-07-07 14:32 ` [PATCH v4 3/7] can: bcm: add locking when updating filter and timer values Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:48   ` sashiko-bot
2026-07-07 14:32 ` [PATCH v4 4/7] can: bcm: fix CAN frame rx/tx statistics Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:54   ` sashiko-bot
2026-07-07 14:32 ` [PATCH v4 5/7] can: bcm: add missing rcu list annotations and operations Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:49   ` sashiko-bot
2026-07-07 14:32 ` [PATCH v4 6/7] can: bcm: extend bcm_tx_lock usage for data and timer updates Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:38   ` Marc Kleine-Budde
2026-07-07 14:48     ` Oliver Hartkopp
2026-07-07 14:32 ` [PATCH v4 7/7] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Oliver Hartkopp
2026-07-07 14:32   ` Oliver Hartkopp via B4 Relay
2026-07-07 14:51   ` sashiko-bot [this message]

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=20260707145135.5BC831F00A3A@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 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.