Re: [PATCH v15 01/11] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
[email protected] Tue, 14 Jul 2026 17:19:35 +0000
| Newsgroups | org.kernel.vger.linux-can |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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/[email protected]?part=1