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>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH v9 03/10] can: bcm: add locking when updating filter and timer values
Date: Thu, 09 Jul 2026 08:31:06 +0000	[thread overview]
Message-ID: <20260709083106.7E0901F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709-bcm_fixes-v9-3-6eebb78ccfb2@hartkopp.net>

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

Pre-existing issues:
- [Medium] Lockless updates of RX metadata (`rx_stamp`, `rx_ifindex`, `frames_abs`) lead to torn reads, lost increments, and corrupted timestamps.
--

--- Patch [3]: [PATCH v9 03/10] can: bcm: add locking when updating filter and timer values ---
commit 10b4ca432b89b6bdfb7aab7948a13f81a6bc41ed
Author: Oliver Hartkopp <socketcan@hartkopp.net>

can: bcm: add locking when updating filter and timer values

This commit introduces bcm_rx_update_lock to protect the filter and timer
configurations of a bcm_op structure from concurrent accesses. It ensures
that updates via bcm_rx_setup and usages in Rx and timeout handlers do not
race.

Link: https://lore.kernel.org/linux-can/6975d5cf.a00a0220.33ccc7.0022.GAE@google.com/

> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index b612135b017d1..af4bb4182bc29 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c

[ ... ]

> @@ -729,9 +751,18 @@ static void bcm_rx_handler(struct sk_buff *skb, void *data)
>  	/* update statistics */
>  	op->frames_abs++;
>  
> -	if (op->flags & RX_RTR_FRAME) {
> +	/* snapshot the flag under lock: op->flags/op->frames may be updated
> +	 * concurrently by bcm_rx_setup().
> +	 */
> +	spin_lock_bh(&op->bcm_rx_update_lock);

[Severity: Medium]
This is a pre-existing issue, but should the update to op->frames_abs be
protected by the new bcm_rx_update_lock?

If a bcm_op is configured to listen on all interfaces (ifindex == 0) and
receives frames concurrently on multiple CAN interfaces, bcm_rx_handler()
can execute simultaneously on different CPUs.

Because op->frames_abs is updated outside the lock, concurrent writes can
occur, potentially leading to lost statistical increments. Additionally, on
32-bit systems, concurrent writes to 64-bit metadata fields like
op->rx_stamp could lead to torn reads when userspace retrieves them.

Could these metadata fields be moved inside the lock to prevent data
races?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-bcm_fixes-v9-0-6eebb78ccfb2@hartkopp.net?part=3

  reply	other threads:[~2026-07-09  8:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  8:16 [PATCH v9 00/10] can: bcm: collected fixes - final4 :-O Oliver Hartkopp via B4 Relay
2026-07-09  8:16 ` Oliver Hartkopp
2026-07-09  8:16 ` [PATCH v9 01/10] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:34   ` sashiko-bot
2026-07-09  8:16 ` [PATCH v9 02/10] can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:36   ` sashiko-bot
2026-07-09  8:16 ` [PATCH v9 03/10] can: bcm: add locking when updating filter and timer values Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:31   ` sashiko-bot [this message]
2026-07-09  8:16 ` [PATCH v9 04/10] can: bcm: fix CAN frame rx/tx statistics Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:31   ` sashiko-bot
2026-07-09  8:16 ` [PATCH v9 05/10] can: bcm: add missing rcu list annotations and operations Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:16 ` [PATCH v9 06/10] can: bcm: extend bcm_tx_lock usage for data and timer updates Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:16 ` [PATCH v9 07/10] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:16 ` [PATCH v9 08/10] can: bcm: add missing device refcount for CAN filter removal Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:39   ` sashiko-bot
2026-07-09  8:16 ` [PATCH v9 09/10] can: bcm: fix stale rx/tx ops after device removal Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp
2026-07-09  8:16 ` [PATCH v9 10/10] can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() Oliver Hartkopp via B4 Relay
2026-07-09  8:16   ` Oliver Hartkopp

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=20260709083106.7E0901F000E9@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.