From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
linux-can@vger.kernel.org
Subject: Re: [PATCH v5 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
Date: Fri, 10 Jul 2026 16:58:50 +0000 [thread overview]
Message-ID: <20260710165850.968E81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710-isotp-fixes-v5-2-15174d82d6f1@hartkopp.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing rx.state validation in isotp_bind() allows cross-interface data corruption and spurious timeouts.
--
--- Patch [2]: [PATCH v5 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER ---
commit 84cdeb4490291132fa60d9c7c68c759beafa051d
Author: Oliver Hartkopp <socketcan@hartkopp.net>
can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
This patch fixes a use-after-free race by holding a tracked reference to
the bound net_device in the socket from bind() onward. It also serializes
bind() and release() with rtnl_lock() and adds a check to reject binding
if the transmission state is not idle.
Link: https://lore.kernel.org/linux-can/20260707101420.47F261F000E9@smtp.kernel.org/
> --- a/net/can/isotp.c
> +++ b/net/can/isotp.c
[ ... ]
> @@ -1317,6 +1327,17 @@ static int isotp_bind(struct socket *sock, struct sockaddr_unsized *uaddr, int l
> goto out;
> }
>
> + /* A transmission that outlived a previous binding (unbound by
> + * NETDEV_UNREGISTER) may still be draining; the FC/echo watchdog
> + * timers bound how long this takes. Checked together with
> + * so->bound in the same lock_sock() section above, so there is no
> + * window in which a concurrent isotp_notify() could be missed.
> + */
> + if (so->tx.state != ISOTP_IDLE) {
> + err = -EAGAIN;
> + goto out;
> + }
> +
[Severity: High]
This is a pre-existing issue, but should we also validate so->rx.state here?
If a multi-frame ISOTP message is being received (ISOTP_WAIT_DATA state
with rxtimer armed) during a concurrent NETDEV_UNREGISTER, the socket is
unbound but so->rx.state and rxtimer remain active.
If the user quickly re-binds to a new interface, would consecutive CAN frames
on the newly bound interface be erroneously appended to the old buffer from
the deleted interface?
Could this also cause the legacy rxtimer to spuriously set sk_err = ETIMEDOUT
on the new connection?
> /* ensure different CAN IDs when the rx_id is to be registered */
> if (isotp_register_rxid(so) && rx_id == tx_id) {
> err = -EADDRNOTAVAIL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-isotp-fixes-v5-0-15174d82d6f1@hartkopp.net?part=2
next prev parent reply other threads:[~2026-07-10 16:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 16:47 [PATCH v5 0/4] net: can: isotp-fixes Oliver Hartkopp via B4 Relay
2026-07-10 16:47 ` [PATCH v5 1/4] can: isotp: use unconditional synchronize_rcu() in isotp_release() Oliver Hartkopp via B4 Relay
2026-07-10 17:05 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v5 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER Oliver Hartkopp via B4 Relay
2026-07-10 16:58 ` sashiko-bot [this message]
2026-07-10 16:47 ` [PATCH v5 3/4] can: isotp: fix race between RX timer and consecutive frame reception Oliver Hartkopp via B4 Relay
2026-07-10 17:02 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v5 4/4] can: isotp: fix lock-free state transition in tx timer handler Oliver Hartkopp via B4 Relay
2026-07-10 17:02 ` sashiko-bot
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=20260710165850.968E81F000E9@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