Linux CAN drivers development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"Vincent Mailhol" <mailhol@kernel.org>,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH v14 05/11] can: bcm: add missing rcu list annotations and operations
Date: Tue, 14 Jul 2026 11:40:45 +0000	[thread overview]
Message-ID: <20260714114045.D2D621F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-bcm_fixes-v14-5-867a4be60a61@hartkopp.net>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Calling `list_add_rcu()` on an existing `bcm_op` structure causes list corruption when an existing RX operation is re-registered.
- [High] Missing `list_del_rcu()` on the error path causes an existing `bcm_op` to be freed while still in the socket's list.
--

--- Patch [5]: [PATCH v14 05/11] can: bcm: add missing rcu list annotations and operations ---
commit c7e6469266e632779d9cd09483b591c4201b8a0d
Author: Oliver Hartkopp <socketcan@hartkopp.net>

can: bcm: add missing rcu list annotations and operations

This commit updates bcm_rx_setup() and bcm_tx_setup() to use list_add_rcu()
when adding operations, ensuring the bcm_op structure is properly initialized
before traversal. It also updates bcm_release() to correctly unlink ops using
list_del_rcu() before freeing them.

Link: https://lore.kernel.org/linux-can/20260610094654.A1FFE1F00893@smtp.kernel.org/

> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index 38c3f690c1cd0..940cd9df1cca3 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c

[ ... ]

> @@ -1431,10 +1432,12 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
>  					      bcm_rx_handler, op, "bcm", sk);
>  		if (err) {
>  			/* this bcm rx op is broken -> remove it */
> -			list_del_rcu(&op->list);
>  			bcm_remove_op(op);
>  			return err;
>  		}

[Severity: High]
Does removing this list_del_rcu() introduce a use-after-free if an existing
operation fails to re-register?

If a virtual CAN interface is unregistered, the netdev notifier sets
op->rx_reg_dev to NULL but keeps the op in bo->rx_ops. If the socket updates
the RX operation while the interface is still gone, bcm_rx_setup() sets
do_rx_register = 1. If dev_get_by_index() then fails and returns an error,
this path is taken.

Since list_del_rcu() was removed, bcm_remove_op() will free the operation
via call_rcu() while it is still linked in bo->rx_ops, which could lead to
a crash during subsequent RCU list traversals.

> +
> +		/* add this bcm_op to the list of the rx_ops */
> +		list_add_rcu(&op->list, &bo->rx_ops);

[Severity: High]
Does this unconditionally add the operation to the list, even if it is an
existing operation that is already linked?

Similar to the previous case, if an existing op is being updated and needs to
be re-registered because op->rx_reg_dev was cleared by a netdev unregister
event, do_rx_register is true. 

If the registration succeeds, will this call list_add_rcu() on an op that
is already in bo->rx_ops, overwriting its list pointers and corrupting the
list?

>  	}
>  
>  	return msg_head->nframes * op->cfsiz + MHSIZ;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-bcm_fixes-v14-0-867a4be60a61@hartkopp.net?part=5

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

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 11:30 [PATCH v14 00/11] can: bcm: collected fixes Oliver Hartkopp via B4 Relay
2026-07-14 11:30 ` [PATCH v14 01/11] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Oliver Hartkopp via B4 Relay
2026-07-14 11:57   ` sashiko-bot
2026-07-14 11:30 ` [PATCH v14 02/11] can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure Oliver Hartkopp via B4 Relay
2026-07-14 11:51   ` sashiko-bot
2026-07-14 11:30 ` [PATCH v14 03/11] can: bcm: add locking when updating filter and timer values Oliver Hartkopp via B4 Relay
2026-07-14 11:52   ` sashiko-bot
2026-07-14 11:30 ` [PATCH v14 04/11] can: bcm: fix CAN frame rx/tx statistics Oliver Hartkopp via B4 Relay
2026-07-14 11:45   ` sashiko-bot
2026-07-14 11:30 ` [PATCH v14 05/11] can: bcm: add missing rcu list annotations and operations Oliver Hartkopp via B4 Relay
2026-07-14 11:40   ` sashiko-bot [this message]
2026-07-14 11:30 ` [PATCH v14 06/11] can: bcm: extend bcm_tx_lock usage for data and timer updates Oliver Hartkopp via B4 Relay
2026-07-14 11:49   ` sashiko-bot
2026-07-14 11:30 ` [PATCH v14 07/11] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Oliver Hartkopp via B4 Relay
2026-07-14 11:30 ` [PATCH v14 08/11] can: bcm: add missing device refcount for CAN filter removal Oliver Hartkopp via B4 Relay
2026-07-14 11:30 ` [PATCH v14 09/11] can: bcm: fix stale rx/tx ops after device removal Oliver Hartkopp via B4 Relay
2026-07-14 11:30 ` [PATCH v14 10/11] can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() Oliver Hartkopp via B4 Relay
2026-07-14 11:30 ` [PATCH v14 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=20260714114045.D2D621F000E9@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