From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Oleksij Rempel" <o.rempel@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
linux-can@vger.kernel.org,
"Marc Kleine-Budde" <mkl@pengutronix.de>
Subject: Re: [PATCH v13 04/11] can: bcm: fix CAN frame rx/tx statistics
Date: Tue, 14 Jul 2026 10:33:00 +0000 [thread overview]
Message-ID: <20260714103300.8B6391F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-bcm_fixes-v13-4-fd667c61099a@hartkopp.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing RCU list primitives lead to potential NULL pointer dereference or memory corruption during lockless /proc/net/can-bcm/... traversal.
--
--- Patch [4]: [PATCH v13 04/11] can: bcm: fix CAN frame rx/tx statistics ---
commit acb95cd7e83f916c374a2a2f75ed2b971c9fa9d5
Author: Oliver Hartkopp <socketcan@hartkopp.net>
can: bcm: fix CAN frame rx/tx statistics
This commit fixes a data race detected by KCSAN when two CAN frames are
simultaneously received and processed by different CPUs. It transitions
the statistics counters to use atomic operations to prevent races.
Additionally, it simplifies overflow checks and consolidates rx statistics
updates into a single critical section.
> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index af4bb4182bc29..38c3f690c1cd0 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c
> @@ -229,10 +229,13 @@ static int bcm_proc_show(struct seq_file *m, void *v)
>
> list_for_each_entry_rcu(op, &bo->rx_ops, list) {
>
> - unsigned long reduction;
> + long reduction, frames_filtered, frames_abs;
> +
[ ... ]
> @@ -280,7 +283,8 @@ static int bcm_proc_show(struct seq_file *m, void *v)
> seq_printf(m, "t2=%lld ",
> (long long)ktime_to_us(op->kt_ival2));
>
> - seq_printf(m, "# sent %ld\n", op->frames_abs);
> + seq_printf(m, "# sent %ld\n",
> + atomic_long_read(&op->frames_abs));
> }
[Severity: High]
This is a pre-existing issue, but while reviewing this code we noticed a
potential missing RCU primitive issue.
In bcm_proc_show(), the code traverses the bo->tx_ops list (which contains
the loop printing the tx stats above) using list_for_each_entry() instead
of list_for_each_entry_rcu(). This omits the READ_ONCE() dependency ordering
required for safe lockless traversal under rcu_read_lock().
Additionally, when adding to these lists in bcm_tx_setup() and
bcm_rx_setup(), the code uses the non-RCU list_add() primitive instead of
list_add_rcu(), which omits the required smp_store_release() semantics.
Since a user can repeatedly read the procfs file for a CAN_BCM socket while
another thread concurrently adds filters on the same socket, could this
expose lockless readers to uninitialized memory and lead to memory corruption
or wild pointer dereferences?
> seq_putc(m, '\n');
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-bcm_fixes-v13-0-fd667c61099a@hartkopp.net?part=4
next prev parent reply other threads:[~2026-07-14 10:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 10:12 [PATCH v13 00/11] can: bcm: collected fixes - final final Oliver Hartkopp via B4 Relay
2026-07-14 10:12 ` [PATCH v13 01/11] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Oliver Hartkopp via B4 Relay
2026-07-14 10:39 ` sashiko-bot
2026-07-14 10:42 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 02/11] can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure Oliver Hartkopp via B4 Relay
2026-07-14 10:33 ` sashiko-bot
2026-07-14 10:41 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 03/11] can: bcm: add locking when updating filter and timer values Oliver Hartkopp via B4 Relay
2026-07-14 10:27 ` sashiko-bot
2026-07-14 10:34 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 04/11] can: bcm: fix CAN frame rx/tx statistics Oliver Hartkopp via B4 Relay
2026-07-14 10:33 ` sashiko-bot [this message]
2026-07-14 10:35 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 05/11] can: bcm: add missing rcu list annotations and operations Oliver Hartkopp via B4 Relay
2026-07-14 10:32 ` sashiko-bot
2026-07-14 10:46 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 06/11] can: bcm: extend bcm_tx_lock usage for data and timer updates Oliver Hartkopp via B4 Relay
2026-07-14 10:34 ` sashiko-bot
2026-07-14 10:56 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 07/11] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Oliver Hartkopp via B4 Relay
2026-07-14 10:12 ` [PATCH v13 08/11] can: bcm: add missing device refcount for CAN filter removal Oliver Hartkopp via B4 Relay
2026-07-14 10:12 ` [PATCH v13 09/11] can: bcm: fix stale rx/tx ops after device removal Oliver Hartkopp via B4 Relay
2026-07-14 10:44 ` sashiko-bot
2026-07-14 11:24 ` Oliver Hartkopp
2026-07-14 11:41 ` Marc Kleine-Budde
2026-07-14 11:47 ` Oliver Hartkopp
2026-07-14 12:36 ` Marc Kleine-Budde
2026-07-14 13:07 ` Oliver Hartkopp
2026-07-14 13:41 ` Marc Kleine-Budde
2026-07-14 14:40 ` Oliver Hartkopp
2026-07-14 10:12 ` [PATCH v13 10/11] can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() Oliver Hartkopp via B4 Relay
2026-07-14 10:12 ` [PATCH v13 11/11] can: bcm: track a single source interface for ANYDEV timeout/throttle ops Oliver Hartkopp via B4 Relay
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=20260714103300.8B6391F000E9@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