From nobody Fri Sep 25 00:40:33 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 861E928DB54; Fri, 18 Sep 2026 02:56:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789700227; cv=none; b=Riy/fASR3iB+U2HOEZbgP7D90tOc1QAQF8Zs3sp0KPsVlZaMVxDol5ER+b6wUQw1JIoB6i9SweV5InhjoONSfKFXaHdTlES4XDTi/5m5fvvCCijHhUmfGKfz7Rju44wH9Dhi25w36G6HSSRWztX3y4oJF6r5ASeHHAtTCWJpm5I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789700227; c=relaxed/simple; bh=BU6Gow1GkXgMlkSVzOBNAwJivG+3VA2dm+yN6Q06WzM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IopbCpYHqbLntFayC7dpPUcqJG1yCbJDaVU/LjuYXhJqcVhknkUKUJ3gra11vyuZ4riTJaGjaX+Mg121dnvZhzeNrPCIH9jlOyGYhmI3nB6SyaqZkF5t7qaiuwDOJazpq4VLKEu7bryhVlaE7gcIbKniaonlu9CbmWHBOF73iiA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=AbDpmFXD; arc=none smtp.client-ip=220.197.31.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="AbDpmFXD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=09 lAaBv/6Y9GQDR0tK0e/kF1ZYd5mbxpJg3UKvI5uZM=; b=AbDpmFXDe+qnmbN0HQ yJYHLNr1MEdnkDjO8IkwUQznO7jIcKYZHNf/VBZ906p8ZzB4y+jnflUeINKbYukz MXnfDYMxihZwaX9Yoi0pkKiYbdypw1pABoGP5YLAbDyR6pjx8Sb7ft1qdnvtWuge nejFQJrHGmOJY6ltG8zNTExfk= Received: from vd-VMware-Virtual-Platform.localdomain (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wD3X+FaqKxqMQl+BQ--.61271S3; Fri, 18 Sep 2026 10:56:32 +0800 (CST) From: Xue Boyang To: robin@protonic.nl, o.rempel@pengutronix.de, socketcan@hartkopp.net, mkl@pengutronix.de, kernel@pengutronix.de Cc: linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, m18335910246@163.com Subject: [PATCH net 1/2] can: j1939: fix null-ptr-deref in j1939_session_completed() Date: Thu, 17 Sep 2026 21:56:14 -0500 Message-ID: <20260918025622.192582-2-m18335910246@163.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260918025622.192582-1-m18335910246@163.com> References: <20260918025622.192582-1-m18335910246@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3X+FaqKxqMQl+BQ--.61271S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxZr43Ar1kKw4kAF1kGF17Wrg_yoW5AF13pF y3CryUGrZ7Zr1UAr48trWDXryFvanakFyrGw1Fg3sxA3sxCa15tF4UtFyS9a98Gan5ua43 uasrXw1DKw40g3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pioa0PUUUUU= X-CM-SenderInfo: zpryjjavzrijiuw6il2tof0z/xtbC8QAItmqsqGAd0AAA3M Content-Type: text/plain; charset="utf-8" j1939_session_completed() distributes the reassembled message to all matching receivers via j1939_sk_recv(). The skb is obtained from j1939_session_skb_get(), which looks up the receive queue starting at session->pkt.dpo * 7 and returns NULL if no queued skb covers that offset. The DPO (Data Packet Offset) command is accepted without validation in j1939_xtp_rx_dpo_one(), so a peer can move pkt.dpo to a packet number beyond the end of the reassembled buffer. The TP.DT placement uses "dat[0] - 1 + session->pkt.dpo" arithmetic, so with pkt.dpo =3D=3D pkt.total a final DT frame with dat[0] =3D=3D 0 is still accepted as the last in-order packet (packet =3D=3D rx) and the transfer completes normally. j1939_session_completed() then looks up the offset pkt.total * 7, which is outside the receive buffer, so j1939_session_skb_get() returns NULL and it is passed to j1939_sk_recv(), which dereferences it via j1939_skb_to_cb(). This is reachable by an unprivileged user through a virtual CAN interface (all required capabilities are obtainable in a user namespace) with the frame sequence: ETP.CM_RTS (size 1786) -> total =3D 256 packets ETP.CM_DPO (packet 0) ETP.DT x255 -> packets 0..254, rx =3D 255 ETP.CM_DPO (packet 256) -> dpo =3D 256, unvalidated ETP.DT (dat[0] =3D 0) -> packet 255 =3D=3D rx, completes transfer resulting in: KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:j1939_sk_recv+0xd8/0x4b0 Call Trace: ? j1939_session_skb_get_by_offset+0x14f/0x2a0 j1939_xtp_rx_eoma+0x43d/0x500 j1939_tp_recv+0x930/0xca0 j1939_can_recv+0x696/0x900 can_rcv_filter+0x223/0x760 can_receive+0x222/0x310 can_rcv+0x204/0x370 (j1939_session_completed() is inlined into j1939_xtp_rx_eoma() in this build; trace taken from v7.3.0-rc3-00313-gdaf677c2c644 + KASAN.) The only other caller of j1939_session_skb_get(), j1939_simple_txnext(), already checks for NULL; do the same here and skip the distribution while still running j1939_session_deactivate_activate_next() so the session is not left stuck. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Xue Boyang --- net/can/j1939/transport.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 8fcfd13e5e6f..ecf7f245f837 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1244,8 +1244,10 @@ static void j1939_session_completed(struct j1939_ses= sion *session) if (!session->transmission) { se_skb =3D j1939_session_skb_get(session); /* distribute among j1939 receivers */ - j1939_sk_recv(session->priv, se_skb); - consume_skb(se_skb); + if (se_skb) { + j1939_sk_recv(session->priv, se_skb); + consume_skb(se_skb); + } } =20 j1939_session_deactivate_activate_next(session); --=20 2.53.0 From nobody Fri Sep 25 00:40:33 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C47F5392828; Fri, 18 Sep 2026 02:56:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789700228; cv=none; b=J0g3LPnO0IMeklypMG+dnvDda2UpA9ZYqyyNVeUDoQ8GbkA5q7F+3G70qkn+EZyZ2bMEdSfAQz49kduuswTYzSZYOjxBYUXKy61FUhCYXd/TBdFmQmUZrwWxNBHCqxuz5w3lN74GhXd3o/Yhki2uqbhJc/Yy0b59akqTBTHBs5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789700228; c=relaxed/simple; bh=mBRqEP9TJjgmRTXwCpPUVGDXgTHCHpr1a1HFzB8joJo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tLX/7I2wuMKz+m/MbtItiFeopjul8Fnqn6bRMnJOdjWIzQfUMpFs1XGTgL/s/hr2hEdrh2fct8oILSgVlc96/xINjxuqKg/1CtBMm902div4E/AIlU6dpRwxZ+IC4bBSiqBPo5wE3oja3YNHJxhMZAGAZPhIL7Qe15ROkzytB3M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=KK/OwESd; arc=none smtp.client-ip=117.135.210.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="KK/OwESd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=Il KVeaotHjF+lLwtJywJovhhhgtimgz6FNhz94t1SkQ=; b=KK/OwESdBlCqqB2tlk 3czWr1mtqj0vpToCm6yjyCzTGXUO/bH3Rq+f+kVxDSBlc7Ba+ejmnJG9kDUmhlSs 9bxPV9b6D7nkbEr3+3F0a5BzMz55ZxDF+AxAdjrsfnFgkK6WOl06CK22Q/XrzCYV 1o7NHvOYEKnhWorBPqD+TdUjI= Received: from vd-VMware-Virtual-Platform.localdomain (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wD3X+FaqKxqMQl+BQ--.61271S4; Fri, 18 Sep 2026 10:56:35 +0800 (CST) From: Xue Boyang To: robin@protonic.nl, o.rempel@pengutronix.de, socketcan@hartkopp.net, mkl@pengutronix.de, kernel@pengutronix.de Cc: linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, m18335910246@163.com Subject: [PATCH net 2/2] can: j1939: validate the DPO packet number Date: Thu, 17 Sep 2026 21:56:15 -0500 Message-ID: <20260918025622.192582-3-m18335910246@163.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260918025622.192582-1-m18335910246@163.com> References: <20260918025622.192582-1-m18335910246@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3X+FaqKxqMQl+BQ--.61271S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7CF45Kw4kAw13Xw18KryfZwb_yoW8CFyxpF Wak34UKryxGrsFyr48tFZ5XryI9Fn3J347WF1jy3s3Cwn8AFWrtFn0kFZFgayDGw4fuay3 u3W2qa9rG34vq37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pi8nY7UUUUU= X-CM-SenderInfo: zpryjjavzrijiuw6il2tof0z/xtbC8gMItmqsqGMgTwAA3t Content-Type: text/plain; charset="utf-8" j1939_xtp_rx_dpo_one() copies the 18-bit packet number of the ETP.CM_DPO command into session->pkt.dpo without any sanity check. The value is later used as a byte offset (pkt.dpo * 7) by j1939_session_skb_get_by_offset(), both for TP.DT placement (combined with dat[0] - 1) and for the final message distribution in j1939_session_completed(). A DPO pointing past the end of the transfer has no valid meaning: every legal window rebase satisfies pkt.dpo <=3D pkt.total. Reject out-of-range values and abort the session with J1939_XTP_ABORT_FAULT instead of carrying them around, mirroring the error handling of j1939_xtp_rx_dat_one(). Note that pkt.dpo =3D=3D pkt.total combined with a DT frame of dat[0] =3D=3D 0 still encodes the final packet (dat[0] - 1 + pkt.dpo =3D=3D pkt.total - 1) and therefore stays accepted by design; the NULL handling in j1939_session_completed() from the previous patch covers this case. This patch only discards the clearly bogus values, so the receive path no longer operates on offsets far outside the buffer. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Xue Boyang --- net/can/j1939/transport.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index ecf7f245f837..b09983d9c19c 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1833,6 +1833,11 @@ static void j1939_xtp_rx_dpo_one(struct j1939_sessio= n *session, =20 /* transmitted without problems */ session->pkt.dpo =3D j1939_etp_ctl_to_packet(skb->data); + if (session->pkt.dpo > session->pkt.total) { + j1939_session_timers_cancel(session); + j1939_session_cancel(session, J1939_XTP_ABORT_FAULT); + return; + } session->last_cmd =3D dat[0]; j1939_tp_set_rxtimeout(session, 750); =20 --=20 2.53.0