[PATCH net v2 0/2] can: j1939: tighten TP receive-path checks

[PATCH net v2 0/2] can: j1939: tighten TP receive-path checks

[Liu Chao]

j1939_xtp_rx_rts_session_new() allocates the receive buffer based on
the message size from RTS dat[1..2], but then overwrites pkt.total
with dat[3] even when they disagree.  A sender can set dat[3] smaller
so the session completes after fewer packets than the buffer was sized
for, delivering a short message to userspace.  With dat[3]=0 the
session just hangs until timeout.

eb96c5890792 ("can: j1939: transport: j1939_session_fresh_new():
initialize receive buffer") addressed a related symptom by zeroing the
receive buffer, but the root cause -- blindly trusting dat[3] -- is
still there.

Patch 1 aborts the session when dat[3] does not match.
Patch 2 adds a pkt.rx check in the EOMA handler for unicast receive
sessions (BAM completes via the final flag in j1939_xtp_rx_dat_one,
not through EOMA).

Note: The handling of sessions already in WAITING_ABORT in
j1939_session_cancel() is fragile in general -- the cts_one and
dat_one cancel paths carry the same hazard unguarded.  The pre-existing
AB-BA deadlock between active_session_list_lock and the rxtimer callback
is likewise not addressed; this series does not change the locking.
Both belong in separate patches.

v2:
  - keep the EOMA size-mismatch warning for transmitter sessions (was
    inadvertently suppressed in v1 by the !session->transmission guard)
  - guard out_session_cancel against J1939_SESSION_WAITING_ABORT state
  - add 'net' to subject prefix
  - use netdev_warn_once for the new warnings to limit log spam from
    malicious frames
  - fix format specifiers: %u for unsigned, %d for int
  - drop redundant dat[3] == 0 check (a zero count already fails the
    != pkt.total test, since pkt.total >= 2 for TP)
  - patch 1: explain why neither direction of mismatch works today

  The first two items address the sashiko-bot review of patch 2:
  https://lore.kernel.org/all/20260908145715.D70BD1F00A3D@smtp.kernel.org/

v1: https://lore.kernel.org/all/20260907145640.1106170-1-liuc63@xiaopeng.com/

Liu Chao (2):
  can: j1939: reject TP RTS with wrong packet count
  can: j1939: check received packet count before completing session

 net/can/j1939/transport.c | 41 +++++++++++++++++++++++++++++++++------
 1 file changed, 35 insertions(+), 6 deletions(-)

-- 
2.50.1

[PATCH net v2 1/2] can: j1939: reject TP RTS with wrong packet count

[Liu Chao]

j1939_xtp_rx_rts_session_new() computes the expected packet count as
(len + 6) / 7, then unconditionally overwrites it with dat[3] from
the incoming RTS, even when the two disagree.  When dat[3] is smaller,
the session completes after fewer packets than the buffer was sized
for, delivering a short (zero-padded) message to userspace.

Neither direction of mismatch works today: a smaller dat[3] completes
the session early and hands a truncated message to userspace, while a
larger one makes j1939_session_skb_get_by_offset() fail once the
offset runs past the buffer, aborting the session anyway.  Rejecting
the RTS up front does not break any transfer that currently works.

Abort the session when dat[3] doesn't match, similar to how
a4fbe70c5cb7 ("can: j1939: j1939_xtp_rx_rts_session_new(): abort
TP less than 9 bytes") rejects out-of-range message sizes.

An alternative would be to silently keep the computed value and ignore
dat[3], but that doesn't actually work: the sender only transmits
dat[3] packets, so the receiver would never collect enough to complete
and would hang until the rx timeout fires -- a worse failure mode than
a clean abort with a clear log message.

  # RTS: len=100 (dat[1..2]=0x0064) but dat[3]=1 (should be 15)
  cansend vcan0 18EC8090#1064000103002301

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Cc: stable@vger.kernel.org
Signed-off-by: Liu Chao <liuc63@xiaopeng.com>
---
 net/can/j1939/transport.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index 8fcfd13e5..c40db4337 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -1672,11 +1672,16 @@ j1939_session *j1939_xtp_rx_rts_session_new(struct j1939_priv *priv,
 	session->pkt.total = (len + 6) / 7;
 	session->pkt.block = 0xff;
 	if (skcb.addr.type != J1939_ETP) {
-		if (dat[3] != session->pkt.total)
-			netdev_alert(priv->ndev, "%s: 0x%p: strange total, %u != %u\n",
-				     __func__, session, session->pkt.total,
-				     dat[3]);
-		session->pkt.total = dat[3];
+		if (dat[3] != session->pkt.total) {
+			netdev_warn_once(priv->ndev,
+					 "%s: 0x%p: packet count mismatch, calc %u != RTS %u, abort\n",
+					 __func__, session,
+					 session->pkt.total, dat[3]);
+			j1939_xtp_tx_abort(priv, &skcb, true,
+					   J1939_XTP_ABORT_FAULT, pgn);
+			j1939_session_put(session);
+			return NULL;
+		}
 		session->pkt.block = min(dat[3], dat[4]);
 	}
 
-- 
2.50.1

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

[Liu Chao]

j1939_xtp_rx_eoma_one() marks a session complete as soon as it sees
an EOMA without verifying that all data packets arrived.  Add a pkt.rx
check so a session with missing packets gets aborted instead of
delivering a short message to userspace.

Also tighten the existing EOMA size-mismatch warning to actually abort
for receive sessions instead of just logging.  The warning itself is
kept for both rx and tx paths so transmitter-side protocol violations
are still logged.

Only unicast receive sessions are gated:

 - Transmitter sessions track pkt.rx via loopback confirmations which
   may legitimately lag behind the real transmit count, so the check
   would cause false aborts on the tx path.

 - BAM (broadcast) sessions never go through EOMA -- they complete via
   the final flag in j1939_xtp_rx_dat_one() when pkt.rx reaches
   pkt.total directly.

The error path skips sessions already in J1939_SESSION_WAITING_ABORT:
cancelling the deactivation timer there would leave the session on
active_session_list forever, since j1939_session_cancel() only re-arms
that timer for sessions which are not yet aborting.  The same failure
mode was previously fixed for the second-RTS path by 1809c82aa073
("net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate
session upon receiving the second rts").

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Cc: stable@vger.kernel.org
Signed-off-by: Liu Chao <liuc63@xiaopeng.com>
---
 net/can/j1939/transport.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index c40db4337..fe447077b 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -1396,6 +1396,7 @@ static void
 j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
 {
 	struct j1939_sk_buff_cb *skcb = j1939_skb_to_cb(skb);
+	unsigned int expected_total;
 	const u8 *dat;
 	int len;
 
@@ -1411,9 +1412,22 @@ j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
 
 	if (session->total_message_size != len) {
 		netdev_warn_once(session->priv->ndev,
-				 "%s: 0x%p: Incorrect size. Expected: %i; got: %i.\n",
+				 "%s: 0x%p: EOMA size mismatch, expected %u got %d\n",
 				 __func__, session, session->total_message_size,
 				 len);
+		if (!session->transmission)
+			goto out_session_cancel;
+	}
+
+	if (!session->transmission) {
+		expected_total = (session->total_message_size + 6) / 7;
+		if (session->pkt.rx < expected_total) {
+			netdev_warn_once(session->priv->ndev,
+					 "%s: 0x%p: EOMA but only %u/%u data packets rx'd\n",
+					 __func__, session,
+					 session->pkt.rx, expected_total);
+			goto out_session_cancel;
+		}
 	}
 
 	netdev_dbg(session->priv->ndev, "%s: 0x%p\n", __func__, session);
@@ -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)
+		return;
+	j1939_session_timers_cancel(session);
+	j1939_session_cancel(session, J1939_XTP_ABORT_FAULT);
 }
 
 static void
-- 
2.50.1

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

[sashiko-bot]

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