CVE-2026-37534: Open-SAE-J1939 Buffer Overflow Vulnerability

CVE-2026-37534 Overview

CVE-2026-37534 is an integer underflow vulnerability [CWE-191] in the Open-SAE-J1939 library, an open-source implementation of the SAE J1939 protocol used for communication between Electronic Control Units (ECUs) on Controller Area Network (CAN) buses. The flaw resides in the SAE_J1939_Read_Transport_Protocol_Data_Transfer function and affects the project through commit b6caf884df46435e539b1ecbf92b6c29b345bdfe dated 2025-11-30. An attacker who can deliver a CAN frame with a crafted sequence number can trigger the underflow and write to arbitrary memory. The vulnerability carries a CVSS 3.1 score of 9.8 with network attack vector and no privileges or user interaction required.

Critical Impact

A single crafted CAN frame allows arbitrary memory writes in J1939 transport protocol handling, enabling code execution or device compromise on automotive and industrial ECUs that link the Open-SAE-J1939 library.

Affected Products

• Open-SAE-J1939 library through commit b6caf884df46435e539b1ecbf92b6c29b345bdfe (2025-11-30)
• ECU firmware and embedded systems integrating the vulnerable Open-SAE-J1939 source tree
• Automotive, agricultural, and heavy-equipment controllers exposing J1939 transport protocol endpoints

Discovery Timeline

• 2026-05-01 - CVE-2026-37534 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-37534

Vulnerability Analysis

The SAE J1939 standard defines a Transport Protocol (TP) for transferring messages larger than the 8-byte CAN payload. Large messages are split into sequenced data transfer frames identified by Parameter Group Number (PGN) 0xEB00. Each Data Transfer frame carries a sequence number in the first data byte, indicating which 7-byte segment of the reassembled buffer it populates.

In SAE_J1939_Read_Transport_Protocol_Data_Transfer, the implementation uses the attacker-controlled sequence number to compute a write offset into the reassembly buffer. The arithmetic does not validate that the sequence number falls within the declared message size, and the offset calculation underflows when crafted values are supplied. The resulting offset wraps around the unsigned integer space and points outside the destination buffer.

Root Cause

The root cause is missing bounds validation on a sequence number sourced directly from an untrusted CAN frame. The function performs offset arithmetic of the form (sequence_number - 1) * 7 and writes 7 bytes from the frame payload into the reassembly buffer at that offset. When the sequence number is 0, the subtraction underflows on unsigned types, producing a very large offset; when sequence numbers exceed the expected message length, the write also lands outside the buffer. Neither the upper nor lower bound is checked against the negotiated transfer size from the prior TP.CM_RTS or TP.CM_BAM connection management frame.

Attack Vector

The attack vector is the CAN bus segment carrying J1939 traffic. An attacker with the ability to inject frames, through a compromised ECU, an exposed OBD-II port, a telematics gateway, or a wireless interface bridged to the CAN bus, sends a TP.CM_BAM or TP.CM_RTS frame to initiate a transport session, then transmits a TP.DT Data Transfer frame with a sequence number chosen to direct the 7-byte write to a target memory address. The write primitive can be used to corrupt control flow structures, function pointers, or adjacent buffers to achieve code execution on the ECU.

No authentication exists at the J1939 protocol layer, and CAN frames are typically processed in interrupt or high-priority task context, giving the resulting memory corruption immediate effect on device state.

Detection Methods for CVE-2026-37534

Indicators of Compromise

• J1939 TP.DT frames (PGN 0xEB00) carrying a sequence number of 0 or values exceeding the count declared in the preceding TP.CM_RTS or TP.CM_BAM frame.
• Unexpected ECU resets, watchdog timeouts, or diagnostic trouble codes appearing shortly after J1939 multi-packet traffic from non-standard source addresses.
• CAN bus traffic originating from source addresses not present in the vehicle or machine's documented address claim table.

Detection Strategies

• Deploy a CAN intrusion detection sensor that parses J1939 transport sessions and flags TP.DT frames whose sequence number is outside [1, total_packets] advertised in the matching connection management frame.
• Correlate CAN telemetry with host-based identifications on telematics gateways and infotainment units that bridge J1939 traffic, using an XDR or SIEM that ingests both vehicle bus logs and Linux endpoint events.
• Hunt for suspicious J1939 source addresses transmitting TP.CM_BAM broadcasts followed by malformed TP.DT sequences across fleet telematics data.

Monitoring Recommendations

• Forward telematics gateway and CAN sniffer logs into a centralized data lake with OCSF normalization for cross-asset correlation, such as the Singularity Data Lake.
• Track firmware build manifests and dependency SBOMs to identify ECUs that link Open-SAE-J1939 at or before commit b6caf884df46435e539b1ecbf92b6c29b345bdfe.
• Alert on bursts of J1939 multi-packet sessions from a single source address that exceed normal operational baselines for the vehicle or machine.

How to Mitigate CVE-2026-37534

Immediate Actions Required

• Inventory all firmware images that integrate the Open-SAE-J1939 source tree and identify devices built from the vulnerable commit or earlier.
• Restrict CAN bus access by disabling unused diagnostic ports and segmenting telematics, infotainment, and ECU networks with gateway filtering.
• Apply gateway-level filtering to drop TP.DT frames whose sequence number is 0 or exceeds the negotiated transfer size for the active session.
• Rebuild and redeploy ECU firmware once a patched version of the library is available upstream.

Patch Information

No fixed commit is referenced in the published advisory at the time of writing. Track the Open-SAE-J1939 GitHub repository for a corrective commit that adds validation of the sequence number against the negotiated total packet count in SAE_J1939_Read_Transport_Protocol_Data_Transfer. Refer to the GitHub Gist code snippet for the underlying code path.

Workarounds

• Patch the local copy of SAE_J1939_Read_Transport_Protocol_Data_Transfer to reject frames whose sequence number is 0 or greater than the total_number_of_packages field cached from the connection management frame.
• Validate that the computed write offset plus 7 bytes remains within the allocated reassembly buffer before each memory copy.
• Disable J1939 transport protocol reception on devices that do not require multi-packet messages, or restrict the function to a known set of trusted source addresses via address-claim allowlists.

# Example bounds check to add inside SAE_J1939_Read_Transport_Protocol_Data_Transfer
if (sequence_number == 0 ||
    sequence_number > j1939->tp.total_number_of_packages) {
    return ERROR_J1939_INVALID_SEQUENCE;
}

size_t offset = (size_t)(sequence_number - 1) * 7U;
if (offset + 7U > j1939->tp.total_message_size) {
    return ERROR_J1939_OFFSET_OUT_OF_RANGE;
}