From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Vincent Mailhol" <mailhol@kernel.org>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
linux-can@vger.kernel.org
Subject: Re: [PATCH v9 01/10] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
Date: Thu, 09 Jul 2026 08:34:27 +0000 [thread overview]
Message-ID: <20260709083428.1B6791F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709-bcm_fixes-v9-1-6eebb78ccfb2@hartkopp.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Module exit triggers a kmem_cache_destroy warning because the protocol slab cache is destroyed before the deferred workqueue frees the remaining sockets.
--
--- Patch [1]: [PATCH v9 01/10] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF ---
commit d847f243125a944d43b2a6970166b528eea27549
Author: Lee Jones <lee@kernel.org>
can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
This commit resolves a use-after-free condition in the broadcast manager
rx operation teardown. It moves the timer cancellation and memory deallocation
to a dedicated unbound workqueue, and ensures the socket reference is held
until the deferred work executes safely in process context.
> 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
[ ... ]
> @@ -1869,6 +1898,8 @@ static void __exit bcm_module_exit(void)
> can_proto_unregister(&bcm_can_proto);
> unregister_netdevice_notifier(&canbcm_notifier);
> unregister_pernet_subsys(&canbcm_pernet_ops);
> + rcu_barrier();
> + destroy_workqueue(bcm_wq);
> }
[Severity: High]
Will this sequence trigger a kmem_cache_destroy warning on module unload?
Since bcm_module_exit() calls can_proto_unregister() before
destroy_workqueue(), the protocol slab cache is destroyed while deferred
work items that release sockets back to the cache might still be pending in
bcm_wq.
Should destroy_workqueue() be called before can_proto_unregister() to
ensure all pending socket frees are completed prior to the protocol slab
cache destruction?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-bcm_fixes-v9-0-6eebb78ccfb2@hartkopp.net?part=1
next prev parent reply other threads:[~2026-07-09 8:34 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 [this message]
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
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=20260709083428.1B6791F000E9@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.