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

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.

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