Fix two issues in net/can/j1939/:

1. In j1939_tp_rxtimer() and session teardown
   (net/can/j1939/transport.c), ensure active transport sessions and
   skbs are properly cancelled and released on error or timeout.
2. In net/can/j1939/socket.c, validate socket state and address fields
   consistently across bind/connect/sendmsg.

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Assisted-by: LLM
Signed-off-by: Hui Peng <benquike@gmail.com>
---
diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index 8fcfd13e5e6f..712bca1174d3 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -1672,10 +1672,15 @@ 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)
+		if (dat[3] != session->pkt.total || !dat[4]) {
 			netdev_alert(priv->ndev, "%s: 0x%p: strange total, %u != %u\n",
 				     __func__, session, session->pkt.total,
 				     dat[3]);
+			j1939_session_put(session);
+			j1939_xtp_tx_abort(priv, &skcb, true,
+					   J1939_XTP_ABORT_FAULT, pgn);
+			return NULL;
+		}
 		session->pkt.total = dat[3];
 		session->pkt.block = min(dat[3], dat[4]);
 	}
diff --git a/net/can/j1939/socket.c b/net/can/j1939/socket.c
index 1d4af472de4a..889d4718c46a 100644
--- a/net/can/j1939/socket.c
+++ b/net/can/j1939/socket.c
@@ -470,6 +470,10 @@ static int j1939_sk_bind(struct socket *sock, struct sockaddr_unsized *uaddr, in
 			ret = -EINVAL;
 			goto out_release_sock;
 		}
+		if (j1939_sock_pending_get(&jsk->sk)) {
+			ret = -EBUSY;
+			goto out_release_sock;
+		}
 
 		/* drop old references */
 		j1939_jsk_del(priv, jsk);

On Sat, Sep 19, 2026 at 10:34:27PM +0000, Hui Peng wrote:
> Fix two issues in net/can/j1939/:
> 
> 1. In j1939_tp_rxtimer() and session teardown
>    (net/can/j1939/transport.c), ensure active transport sessions and
>    skbs are properly cancelled and released on error or timeout.
> 2. In net/can/j1939/socket.c, validate socket state and address fields
>    consistently across bind/connect/sendmsg.

FWIIW, these changes look reasonable to me.
But I think you should make a short patch-set, with a cover letter
and two patch-sei - one patch per fix.

And I think the description needs to describe in a little more detail
what each bug is, and how it is fixed. While it doesn't need
to mention the filename, which is already present in the diff.

Thanks!

On Sat, 19 Sep 2026 22:34:27 +0000, Hui Peng wrote:
> Fix two issues in net/can/j1939/:
> 
> 1. In j1939_tp_rxtimer() and session teardown
>    (net/can/j1939/transport.c), ensure active transport sessions and
>    skbs are properly cancelled and released on error or timeout.
> 2. In net/can/j1939/socket.c, validate socket state and address fields
>    consistently across bind/connect/sendmsg.
> 
> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---


You sent multiple independent patches, to multiple independent
subsystems. The amount of these patches clearly suggest this was
AI generated and most likely not tested.

More importantly, you sent all this work without properly organizing
relevant patches into patchsets. This makes reviewing difficult
and might cause multiple reviewers to address the same issue.
Replying to the entire set is impossible and requires handling each
patch independently, instead of applying or discarding the set.
Maintainers also won't see the bigger picture of your work. Quite
worrying.

This is on the verge of hostile patch: bomb us with so many
contributions, we won't be able to handle them in efficient manner,
like responding ONCE to ask you to slow down.  Considering all this
is untested and LLM generated, I have even more doubts whether this
should be considered for review.

Please read kernel documentation BEFORE posting more work. It will
explain you how to identify subsystems, how to organize your work per
subsystem, how to document usage of LLM and how what you should not
do if this was posted in a good faith.

Best regards,
Krzysztof