From: sashiko-bot@kernel.org
To: "Oliver Hartkopp" <socketcan@hartkopp.net>
Cc: "Vincent Mailhol" <mailhol@kernel.org>,
linux-can@vger.kernel.org,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Oliver Hartkopp" <socketcan@hartkopp.net>
Subject: Re: [PATCH v6] can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
Date: Tue, 21 Jul 2026 09:12:37 +0000 [thread overview]
Message-ID: <20260721091238.2C4C21F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260721085544.15541-1-socketcan@hartkopp.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] TOCTOU race in `isotp_tx_timeout` exposes intermediate state, corrupting error reporting and overwriting subsequent transfer results.
- [High] Silent failure when TX timeout error is overwritten by rapidly completing concurrent transfers, causing false success reports.
--
--- Patch [1]: [PATCH v6] can: isotp: fix timer drain order, wakeup handling and tx_gen ordering ---
commit fc49d60dded5144b72722946923b8f8955622fbf
Author: Oliver Hartkopp <socketcan@hartkopp.net>
can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
This patch addresses sashiko-bot findings by serializing TX state transitions
and handling concurrent claims during wait_tx_done timeouts. It also aligns
lock-free accesses and uses skb->hash as a unique loopback echo frame indicator.
> diff --git a/net/can/isotp.c b/net/can/isotp.c
> index 54becaf6898f1..703d110377f87 100644
> --- a/net/can/isotp.c
> +++ b/net/can/isotp.c
[ ... ]
> @@ -965,10 +1007,10 @@ static enum hrtimer_restart isotp_tx_timeout(struct isotp_sock *so)
> /* only claim the timeout if the state is still unchanged */
> if (cmpxchg(&so->tx.state, old_state, ISOTP_IDLE) != old_state)
> return HRTIMER_NORESTART;
>
> - /* we did not get any flow control or echo frame in time */
> + /* detected timeout: report 'communication error on send' */
> + WRITE_ONCE(so->tx_result, isotp_pack_tx_result(gen, ECOMM));
[Severity: High]
Could this lead to a race condition where a stale error corrupts a new
transfer?
If this thread is preempted immediately after the cmpxchg() sets the state
to ISOTP_IDLE, the socket becomes available for other threads.
A concurrent sendmsg() thread could then claim the socket, increment
so->tx_gen, and complete a new transfer.
When this timeout handler resumes and executes the WRITE_ONCE() above, it
would overwrite the new transfer's result with the stale ECOMM error and
the old generation tag.
Later, when the new transfer's waiter in isotp_sendmsg() reads so->tx_result,
it checks that so->tx_gen still matches its own claim:
isotp_sendmsg() {
...
/* ISOTP_IDLE: so->tx_gen still matches our own claim */
err = isotp_get_tx_err(READ_ONCE(so->tx_result));
if (err)
return -err;
}
Since so->tx_gen matches the new transfer, the waiter extracts the error
without validating the generation tag inside tx_result, falsely returning
-ECOMM instead of success.
>
> if (READ_ONCE(so->tx_gen) == gen) {
> - /* report 'communication error on send' */
> sk->sk_err = ECOMM;
> if (!sock_flag(sk, SOCK_DEAD))
[ ... ]
> @@ -1223,20 +1274,57 @@ static int isotp_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
> if (wait_tx_done) {
> - /* wait for complete transmission of current pdu */
> - err = wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
> + /* wake up for:
> + * - concurrent sendmsg() claiming a new transfer
> + * - complete transmission of current PDU
> + * - shutdown state change in isotp_release()
> + */
> + err = wait_event_interruptible(so->wait,
> + READ_ONCE(so->tx_gen) != my_gen ||
> + READ_ONCE(so->tx.state) == ISOTP_IDLE ||
> + READ_ONCE(so->tx.state) == ISOTP_SHUTDOWN);
> if (err)
> goto err_event_drop;
>
> - err = sock_error(sk);
> + if (READ_ONCE(so->tx_gen) != my_gen) {
> + /* a new transfer has since been claimed - so->tx.state
> + * already belongs to it, but so->tx_result still
> + * carries our own completion status, unless a second
> + * transfer has since completed and overwritten it too
> + */
> + u32 result = READ_ONCE(so->tx_result);
> + int tx_err = 0;
> +
> + if (isotp_get_tx_gen(result) == my_gen)
> + tx_err = isotp_get_tx_err(result);
> +
> + return tx_err ? -tx_err : size;
> + }
[Severity: High]
Can a timed-out transfer falsely return success if its error is overwritten
by a concurrent transfer?
If a transfer times out, so->tx_result is set to the error code and the
waiting sendmsg() thread is woken up.
Before the original thread gets CPU time, a concurrent thread calling
sendmsg() could claim the newly IDLE socket and complete a short transfer.
This successful transfer unconditionally overwrites so->tx_result with 0:
isotp_rcv_echo() {
...
if (so->tx.idx >= so->tx.len) {
/* we are done */
WRITE_ONCE(so->tx_result, isotp_pack_tx_result(so->tx_gen, 0));
WRITE_ONCE(so->tx.state, ISOTP_IDLE);
...
}
When the originally woken thread finally runs, it observes that
READ_ONCE(so->tx_gen) != my_gen and enters this block.
Since the generation tag inside the overwritten tx_result no longer matches
my_gen, it defaults to tx_err = 0 and returns the payload size. This would
cause the application to silently lose data, falsely believing its message
was sent successfully.
> +
> + if (READ_ONCE(so->tx.state) == ISOTP_SHUTDOWN) {
> + /* isotp_release() has taken over the claim */
> + err = -EADDRNOTAVAIL;
> + goto err_event_drop;
> + }
> +
> + /* ISOTP_IDLE: so->tx_gen still matches our own claim */
> + err = isotp_get_tx_err(READ_ONCE(so->tx_result));
> if (err)
> - return err;
> + return -err;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721085544.15541-1-socketcan@hartkopp.net?part=1
prev parent reply other threads:[~2026-07-21 9:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 8:55 [PATCH v6] can: isotp: fix timer drain order, wakeup handling and tx_gen ordering Oliver Hartkopp
2026-07-21 9:12 ` sashiko-bot [this message]
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=20260721091238.2C4C21F00A3A@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