J1939 CAN bug lets local user panic Linux with bad packet offset

A missing bounds check in the Linux kernel's J1939 CAN stack lets an unprivileged local user panic the system through a virtual CAN interface, with no special hardware, race, or memory pressure required.

J1939 is the SAE multi-packet protocol widely used on heavy vehicles and industrial CAN buses. Its Extended Transport Protocol includes a peer-controlled Data Packet Offset (ETP.CM_DPO) message that names where a transmission window starts. The kernel accepted that packet number without checking it against the transfer size, so a value at or past the end of the message could slide the receive window beyond the reassembled buffer.

A crafted sequence still completes the transfer. Session cleanup then requests a socket buffer one full packet past the queued data, receives NULL, and dereferences it in the receive path, panicking from interrupt context. The path is deterministic on vcan.

Quchaosheng reported the flaw and posted a fix that rejects an offset at or beyond the total packet count and aborts the session with the SAE J1939-21 code for a bad EDPO offset. Legitimate transmitters already stay in range because they derive the offset from acknowledged packets, so the check does not break valid peers.