From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org, "Vincent Mailhol" <mailhol@kernel.org>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>
Subject: Re: [PATCH v8 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
Date: Sun, 12 Jul 2026 12:59:59 +0000 [thread overview]
Message-ID: <20260712125959.B72EF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260712-isotp-fixes-v8-2-c39220a4e442@hartkopp.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] A TOCTOU race condition in `isotp_sendmsg` allows concurrent modification of socket options, leading to an SKB heap overflow and `skb_over_panic`.
- [High] The check in `isotp_bind()` to prevent rebinding during an active state machine does not fully prevent cross-interface packet injection from RCU-delayed softirqs.
--
--- Patch [2]: [PATCH v8 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER ---
commit 508c0cfe152e6936d33176beb93ef03692ea4ea7
Author: Oliver Hartkopp <socketcan@hartkopp.net>
can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER
This tracks the bound net_device with a reference instead of re-resolving
it from ifindex during isotp_release(). It also rejects isotp_bind() with
-EAGAIN if the state machines aren't idle yet, avoiding timers acting on a
newly bound interface.
Link: https://lore.kernel.org/linux-can/20260707101420.47F261F000E9@smtp.kernel.org/
> diff --git a/net/can/isotp.c b/net/can/isotp.c
> index d30937345bcdc..44c044eb83e12 100644
> --- a/net/can/isotp.c
> +++ b/net/can/isotp.c
> @@ -978,6 +980,14 @@ static int isotp_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
> goto err_event_drop;
> }
>
> + /* so->bound is only checked once above - a wakeup may have
> + * unbound/rebound the socket meanwhile, so re-validate it
> + */
> + if (!so->bound) {
> + err = -EADDRNOTAVAIL;
> + goto err_out_drop;
> + }
[Severity: Critical]
This is a pre-existing issue, but does a time-of-check to time-of-use race
still exist here if sock_alloc_send_skb() blocks later in isotp_sendmsg()?
If sock_alloc_send_skb(sk, so->ll.mtu) blocks during allocation, a concurrent
NETDEV_UNREGISTER could trigger isotp_notify(), which acquires lock_sock()
and sets so->bound = 0.
Userspace could then call setsockopt(CAN_ISOTP_LL_OPTS), which passes its
!so->bound check and modifies so->ll.mtu and so->tx.ll_dl.
When isotp_sendmsg() resumes, it has a smaller SKB but could use the new
larger MTU, or isotp_fill_dataframe() could use the new so->tx.ll_dl to copy
too many bytes into the small SKB:
net/can/isotp.c:isotp_fill_dataframe() {
...
for (i = 0; i < num; i++)
cf->data[pcilen + i] = so->tx.buf[so->tx.idx++];
...
}
Could this lead to a heap out-of-bounds write overwriting skb_shared_info?
[ ... ]
> @@ -1317,6 +1327,17 @@ static int isotp_bind(struct socket *sock, struct sockaddr_unsized *uaddr, int l
> goto out;
> }
>
> + /* A transmission or reception that outlived a previous binding
> + * (unbound by NETDEV_UNREGISTER) may still be draining; the FC/echo
> + * and RX 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 || so->rx.state != ISOTP_IDLE) {
> + err = -EAGAIN;
> + goto out;
> + }
[Severity: High]
This is a pre-existing issue, but does this state machine check fully prevent
cross-interface packet injection from RCU-delayed softirqs?
If a packet arrives on an old device and is queued via can_rx_register()'s
softirq, and concurrently the device is unregistered (clearing so->bound),
userspace could call bind() for a new device.
Since isotp_rcv() hasn't acquired so->rx_lock to change the state yet, the
lockless check here passes and so->dev is updated. Could the delayed softirq
then acquire so->rx_lock, transition the state, and send a Flow Control frame
using the newly bound so->ifindex?
Would isotp_rcv() need to verify that skb->dev matches the currently bound
so->dev after acquiring so->rx_lock?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260712-isotp-fixes-v8-0-c39220a4e442@hartkopp.net?part=2
next prev parent reply other threads:[~2026-07-12 13:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 12:41 [PATCH v8 0/4] net: can: isotp-fixes Oliver Hartkopp via B4 Relay
2026-07-12 12:41 ` [PATCH v8 1/4] can: isotp: use unconditional synchronize_rcu() in isotp_release() Oliver Hartkopp via B4 Relay
2026-07-12 12:54 ` sashiko-bot
2026-07-12 12:41 ` [PATCH v8 2/4] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER Oliver Hartkopp via B4 Relay
2026-07-12 12:59 ` sashiko-bot [this message]
2026-07-12 12:41 ` [PATCH v8 3/4] can: isotp: fix race between RX/TX timers and frame reception Oliver Hartkopp via B4 Relay
2026-07-12 12:53 ` sashiko-bot
2026-07-12 12:41 ` [PATCH v8 4/4] can: isotp: fix state machine corruption on signal interruption Oliver Hartkopp via B4 Relay
2026-07-12 12:56 ` 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=20260712125959.B72EF1F000E9@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