Re: [PATCH net v2 2/2] can: j1939: check received packet count before completing session

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] A TOCTOU race condition in `j1939_xtp_rx_eoma_one`'s error path leads to a cancelled deactivation timer and a permanent session leak.

Pre-existing issues:
- [High] Unconditional timer cancellation in `j1939_xtp_rx_dat_one` and `j1939_xtp_rx_cts_one` error paths can permanently leak aborting sessions.
- [High] AB-BA deadlock between `j1939_session_list_lock` and `hrtimer_cancel` inside `j1939_session_cancel`.
--

commit 814e4e3f93c71a9da50106bf799262ce6cff348a
Author: Liu Chao <liuc63@xiaopeng.com>

can: j1939: check received packet count before completing session

This commit modifies the j1939 receive path to ensure all data packets
have arrived before completing a session on EOMA. It adds a packet count
verification to prevent delivering incomplete messages to userspace, and
implements a safe abort path when packets are missing.

> diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
> index c40db43379598..fe447077bcc89 100644
> --- a/net/can/j1939/transport.c
> +++ b/net/can/j1939/transport.c

[ ... ]

> @@ -1422,6 +1436,16 @@ j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
>  	j1939_session_timers_cancel(session);
>  	/* transmitted without problems */
>  	j1939_session_completed(session);
> +	return;
> +
> + out_session_cancel:
> +	/* Don't touch timers if the session is already aborting;
> +	 * cancelling the deactivation timer here would leak the session.
> +	 */
> +	if (session->state >= J1939_SESSION_WAITING_ABORT)

[Severity: High]
Can this lockless state check create a TOCTOU race condition?

Because the state check is lockless, another CPU can transition the session
to WAITING_ABORT and arm the deactivation timer after the lockless check but
before timer cancellation. The first CPU then blindly cancels this newly
armed deactivation timer.

The subsequent call to j1939_session_cancel() acquires the lock, sees the
state is already WAITING_ABORT, and skips re-arming the timer, leaving the
session leaked permanently on the active_session_list.

This can be triggered remotely on the CAN bus by sending an invalid EOMA
packet simultaneously with an abort or timeout occurring on another CPU.

> +		return;
> +	j1939_session_timers_cancel(session);

[Severity: High]
This isn't a bug introduced by this patch, but could the unconditional timer
cancellation in the error paths of j1939_xtp_rx_dat_one() and
j1939_xtp_rx_cts_one() permanently leak aborting sessions?

When an invalid DAT or CTS packet is received for an already aborting session,
the code hits the out_session_cancel path which unconditionally calls
j1939_session_timers_cancel():

net/can/j1939/transport.c:j1939_xtp_rx_dat_one() {
    ...
 out_session_cancel:
	kfree_skb(se_skb);
	j1939_session_timers_cancel(session);
	j1939_session_cancel(session, abort);
}

A remote attacker on the CAN bus can cause an abort and quickly follow up
with an invalid DAT or CTS packet. This unconditionally kills the running
deactivation timer because j1939_session_cancel() does not re-arm timers
for sessions already in the WAITING_ABORT state.

> +	j1939_session_cancel(session, J1939_XTP_ABORT_FAULT);

[Severity: High]
This is a pre-existing issue, but does calling hrtimer_cancel() while holding
active_session_list_lock create an AB-BA deadlock?

CPU A executing j1939_session_cancel() acquires active_session_list_lock
and invokes hrtimer_cancel() (via j1939_tp_set_rxtimeout() or
__j1939_session_cancel()).

Concurrently, CPU B executing the j1939_tp_rxtimer() softirq callback
attempts to acquire active_session_list_lock:

net/can/j1939/transport.c:j1939_tp_rxtimer() {
    ...
	} else {
		j1939_session_list_lock(session->priv);
		if (session->state >= J1939_SESSION_ACTIVE &&
    ...
}

hrtimer_cancel() will spin-wait for the timer callback to finish on CPU B,
but CPU B is spinning waiting for the spinlock held by CPU A. This race
can be triggered remotely on SMP systems when an attacker sends a packet
that causes an abort precisely when the receiver timeout timer is firing.

>  }
>  
>  static void

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909173105.158202-1-liuc63@xiaopeng.com?part=2