All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org, "Vincent Mailhol" <mailhol@kernel.org>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH v15 01/11] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
Date: Tue, 14 Jul 2026 17:19:35 +0000	[thread overview]
Message-ID: <20260714171936.6FADE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-bcm_fixes-v15-1-562f7e3e42da@hartkopp.net>

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

Pre-existing issues:
- [High] RCU List API Violation and Data Race in BCM operations list
- [High] Unprotected Data Race modifying CAN frames and filter state from userspace
--

--- Patch [1]: [PATCH v15 01/11] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF ---
commit f443af2888a268be3aea6c068673db99b62a8a27
Author: Lee Jones <lee@kernel.org>

can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF

Commit f1b4e32aca08 replaced synchronize_rcu() with call_rcu() and introduced
the RX_NO_AUTOTIMER flag. This patch resolves a thrtimer UAF by deferring
timer cancellation and memory free to a dedicated unbound workqueue. A
reference on op->sk is also taken to ensure the socket is not freed out from
under an armed timer.

> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index a4bef2c48a559..bdf53241bd7b3 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c

[ ... ]

> @@ -1060,6 +1081,7 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
>  
>  		/* bcm_can_tx / bcm_tx_timeout_handler needs this */
>  		op->sk = sk;
> +		sock_hold(sk);

[Severity: High]
This isn't a bug introduced by this patch, but does bcm_tx_setup() insert into
tx_ops using list_add() without RCU memory release barriers?

When bcm_proc_show() concurrently iterates tx_ops without RCU primitives, can
this missing dependency ordering lead to wild pointer dereferences?

bcm_tx_setup()
    list_add(&op->list, &bo->tx_ops);

bcm_rx_setup()
    list_add(&op->list, &bo->rx_ops);

bcm_proc_show()
    list_for_each_entry(op, &bo->tx_ops, list) {


[Severity: High]
This is a pre-existing issue, but do bcm_tx_setup() and bcm_rx_setup() modify
op->frames directly from user memory without holding their respective spinlocks?

If memcpy_from_msg() modifies op->frames while bcm_can_tx() reads them
concurrently in softirq context, can it result in the transmission of partially
written CAN frames?

bcm_tx_setup()
    err = memcpy_from_msg((u8 *)cf, msg, op->cfsiz);

bcm_rx_setup()
    err = memcpy_from_msg(op->frames, msg, msg_head->nframes * op->cfsiz);

>  		op->ifindex = ifindex;
>  
>  		/* initialize uninitialized (kzalloc) structure */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-bcm_fixes-v15-0-562f7e3e42da@hartkopp.net?part=1

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

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