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

[PATCH 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.

eb96c58907922546 ("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] doesn't 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).

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 | 37 ++++++++++++++++++++++++++++++-------
 1 file changed, 30 insertions(+), 7 deletions(-)

-- 
2.50.1

[PATCH 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.  When
dat[3] is zero, every incoming data packet looks out of range and the
session hangs until the rx timeout fires.

Abort the session when dat[3] doesn't match or is zero, 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@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..8fdce5792 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 || dat[3] == 0) {
+			netdev_warn(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 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.

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.

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

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index 8fdce5792..2ecce49ad 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -1397,6 +1397,7 @@ j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
 {
 	struct j1939_sk_buff_cb *skcb = j1939_skb_to_cb(skb);
 	const u8 *dat;
+	unsigned int expected_total;
 	int len;
 
 	if (j1939_xtp_rx_cmd_bad_pgn(session, skb))
@@ -1409,11 +1410,23 @@ j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
 	else
 		len = j1939_tp_ctl_to_size(dat);
 
-	if (session->total_message_size != len) {
+	if (!session->transmission && 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 %i got %i\n",
 				 __func__, session, session->total_message_size,
 				 len);
+		goto out_session_cancel;
+	}
+
+	if (!session->transmission) {
+		expected_total = (session->total_message_size + 6) / 7;
+		if (session->pkt.rx < expected_total) {
+			netdev_warn(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 +1435,11 @@ 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:
+	j1939_session_timers_cancel(session);
+	j1939_session_cancel(session, J1939_XTP_ABORT_FAULT);
 }
 
 static void
-- 
2.50.1

Re: [PATCH 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] Canceling session timers during an already-aborting session permanently leaks the session and blocks the address.
- [Medium] The patch inadvertently suppresses the pre-existing diagnostic warning for EOMA size mismatches on transmitter sessions.

Pre-existing issues:
- [High] AB-BA deadlock between `active_session_list_lock` and the `rxtimer` hrtimer callback.
--

commit 66292f8eec0fad08cd8484aafc6afd0d99105fbf
Author: Liu Chao <liuc63@xiaopeng.com>

can: j1939: check received packet count before completing session

This commit adds a packet receive count check in j1939_xtp_rx_eoma_one() to
abort sessions with missing data packets instead of delivering short messages.
It also tightens the EOMA size mismatch warning to abort receive sessions.

> diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
> index 8fdce57924042..2ecce49ada40a 100644
> --- a/net/can/j1939/transport.c
> +++ b/net/can/j1939/transport.c
> @@ -1409,11 +1410,23 @@ j1939_xtp_rx_eoma_one(struct j1939_session *session, struct sk_buff *skb)
>  	else
>  		len = j1939_tp_ctl_to_size(dat);
>  
> -	if (session->total_message_size != len) {
> +	if (!session->transmission && session->total_message_size != len) {

[Severity: Medium]
Does this inadvertently suppress the diagnostic warning for EOMA size
mismatches on transmitter sessions? By adding the !session->transmission
condition here, protocol violations (a receiver sending an EOMA with an
incorrect size) are now silently ignored on the transmitter instead of
logging a warning. Could we keep the warning for transmitters but only
bypass the newly-added abort?

> +		netdev_warn_once(session->priv->ndev,
> +				 "%s: 0x%p: EOMA size mismatch, expected %i got %i\n",
> +				 __func__, session, session->total_message_size,
> +				 len);
> +		goto out_session_cancel;
> +	}

[ ... ]

>  	j1939_session_timers_cancel(session);
>  	/* transmitted without problems */
>  	j1939_session_completed(session);
> +	return;
> +
> +out_session_cancel:
> +	j1939_session_timers_cancel(session);
> +	j1939_session_cancel(session, J1939_XTP_ABORT_FAULT);
>  }

[Severity: High]
Could this error path cause a permanent leak of the session structure
and permanently block the SA/DA address pair?

If a receive session times out or is aborted, it enters the
J1939_SESSION_WAITING_ABORT state with a timer scheduled to eventually
deactivate it. If a malformed EOMA arrives while waiting, this path will
call j1939_session_timers_cancel() (which cancels the deactivation timer).

Then, j1939_session_cancel() is called:

j1939_session_cancel() {
    ...
    if (session->state >= J1939_SESSION_ACTIVE &&
        session->state < J1939_SESSION_WAITING_ABORT) {
        j1939_tp_set_rxtimeout(session, J1939_XTP_ABORT_TIMEOUT_MS);
    ...
}

Because the session is already in J1939_SESSION_WAITING_ABORT, the
condition fails and the deactivation timer is never restarted. The session
remains in the active_session_list indefinitely.


[Severity: High]
This is a pre-existing issue, but looking at j1939_session_cancel() exposed
by this path, could it trigger an AB-BA deadlock?

j1939_session_cancel() takes the list lock, then cancels the rx timer:

j1939_session_cancel() {
    j1939_session_list_lock(session->priv);
    ...
    j1939_tp_set_rxtimeout(session, ...); // internally calls hrtimer_cancel
}

Meanwhile, the timer callback attempts to acquire the same list lock:

j1939_tp_rxtimer() {
    ...
    j1939_session_list_lock(session->priv);
}

If j1939_session_cancel() is called exactly when the session's receive
timeout expires, the CPU executing j1939_session_cancel() would spin
waiting for the timer to finish, while the CPU executing j1939_tp_rxtimer()
spins waiting for the list lock, resulting in a deadlock.

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

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

[Liu Chao]

Addressed in v2:
https://lore.kernel.org/all/20260909173105.158202-1-liuc63@xiaopeng.com/

> Does this inadvertently suppress the diagnostic warning for EOMA size
> mismatches on transmitter sessions?

Yes.  v2 emits the warning for both rx and tx and gates only the abort on
!session->transmission.

> Could this error path cause a permanent leak of the session structure
> and permanently block the SA/DA address pair?

v2 returns early for sessions already in J1939_SESSION_WAITING_ABORT, so
the deactivation timer armed by the earlier abort keeps running.  Same
failure mode as 1809c82aa073 ("net: can: j1939:
j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the
second rts").  j1939_session_cancel() is fragile here in general -- the
cts_one and dat_one cancel paths are still unguarded -- but that is a
separate patch.

> This is a pre-existing issue, but looking at j1939_session_cancel()
> exposed by this path, could it trigger an AB-BA deadlock?

Pre-existing, and this series adds no new locking: j1939_xtp_rx_eoma_one()
calls j1939_session_cancel() from the same RX softirq context as the
existing cts_one and dat_one cancel paths, so the reachability of the
cycle is unchanged.  Fixing it means restructuring how
j1939_session_cancel() cancels the rxtimer under active_session_list_lock;
that is a separate change.