CVE-2026-37536: uds-c Buffer Overflow Vulnerability

CVE-2026-37536 Overview

CVE-2026-37536 is a stack buffer overflow [CWE-121] in the miaofng/uds-c library, an implementation of the Unified Diagnostic Services (UDS) protocol used in automotive Controller Area Network (CAN) stacks. The vulnerable code resides in send_diagnostic_request at commit e506334e270d77b20c0bc259ac6c7d8c9b702b7a (2016-10-05). The function copies attacker-controlled payload bytes into a 6-byte stack buffer without validating payload_length, allowing a 4-byte overflow past the buffer boundary. An adjacent-network attacker on the CAN bus can corrupt stack memory in any process linking the affected library.

Critical Impact

A malformed UDS diagnostic request can overwrite stack memory in the calling process, leading to memory corruption, denial of service, or arbitrary code execution on automotive control units that integrate uds-c.

Affected Products

• miaofng/uds-c at commit e506334e270d77b20c0bc259ac6c7d8c9b702b7a (2016-10-05)
• Downstream forks of the UDS-C library, including the OpenXC uds-c repository
• Automotive firmware and diagnostic tools that link the vulnerable send_diagnostic_request implementation

Discovery Timeline

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

Technical Details for CVE-2026-37536

Vulnerability Analysis

The uds-c library implements UDS message construction for CAN-based diagnostics. The function send_diagnostic_request builds an outbound diagnostic message on a fixed-size stack buffer sized by the constant MAX_DIAGNOSTIC_PAYLOAD_SIZE, which is defined as 6 bytes. The function writes the service identifier at offset 0, an optional Parameter Identifier (PID) of up to 2 bytes starting at offset 1, and then copies the caller-supplied payload at offset 1 + pid_length using memcpy.

The library accepts a payload of up to MAX_UDS_REQUEST_PAYLOAD_LENGTH bytes, which is defined as 7. The maximum write therefore reaches 1 + 2 + 7 = 10 bytes, overflowing the 6-byte buffer by 4 bytes. The memcpy is performed without comparing payload_length against the remaining buffer space.

Depending on compiler-emitted stack layout, the overflow can corrupt adjacent local variables, saved registers, frame pointers, or the return address. On embedded targets without stack canaries or position-independent execution, this primitive is sufficient to redirect control flow.

Root Cause

The root cause is a missing bounds check before the memcpy call. The function trusts both pid_length and payload_length from the request structure without validating that 1 + pid_length + payload_length does not exceed MAX_DIAGNOSTIC_PAYLOAD_SIZE. The two compile-time constants MAX_DIAGNOSTIC_PAYLOAD_SIZE=6 and MAX_UDS_REQUEST_PAYLOAD_LENGTH=7 are inconsistent, guaranteeing overflow when callers use the documented maximum payload size.

Attack Vector

The attack vector is adjacent network. An attacker with access to the CAN bus, OBD-II port, or any logical channel that feeds UDS request structures into the library can supply a request with pid_length=2 and payload_length=7. This triggers the 4-byte stack overflow. The flaw requires no authentication and no user interaction. Successful exploitation impacts confidentiality, integrity, and availability of the diagnostic process and any privileges it holds on the embedded controller.

No public exploit code is available beyond the proof-of-concept gist referenced in the GitHub Gist PoC. Refer to the upstream miaofng/uds-c repository for the affected source.

Detection Methods for CVE-2026-37536

Indicators of Compromise

• Unexpected crashes, resets, or watchdog reboots of Electronic Control Units (ECUs) shortly after receiving UDS diagnostic traffic.
• CAN frames carrying UDS requests with payload lengths at or near 7 bytes combined with multi-byte PIDs.
• Diagnostic sessions originating from unauthorized tools or unknown CAN node IDs.

Detection Strategies

• Perform static analysis on firmware images to locate send_diagnostic_request builds derived from commit e506334e, focusing on the absence of a payload_length bounds check before memcpy.
• Build the affected library with AddressSanitizer or stack canaries (-fstack-protector-strong) and fuzz send_diagnostic_request with malformed payload and PID lengths.
• Deploy CAN intrusion detection that flags UDS requests violating service-specific length expectations defined in ISO 14229.

Monitoring Recommendations

• Log all UDS request frames at gateway ECUs, including service ID, sub-function, PID length, and payload length, for offline anomaly review.
• Alert on repeated UDS requests that result in ECU resets or NegativeResponse codes consistent with malformed input.
• Monitor diagnostic tool authentication events and correlate them with bus-level UDS traffic to identify unauthorized sessions.

How to Mitigate CVE-2026-37536

Immediate Actions Required

• Audit firmware and tooling for any link against miaofng/uds-c or its forks at or before commit e506334e270d77b20c0bc259ac6c7d8c9b702b7a.
• Patch send_diagnostic_request to validate 1 + pid_length + payload_length <= MAX_DIAGNOSTIC_PAYLOAD_SIZE before invoking memcpy, and reject requests that exceed the limit.
• Reconcile the library constants so MAX_UDS_REQUEST_PAYLOAD_LENGTH cannot exceed MAX_DIAGNOSTIC_PAYLOAD_SIZE - 1 - max_pid_length.
• Restrict physical and logical access to CAN buses and OBD-II ports on production vehicles and test benches.

Patch Information

No official upstream patch is referenced in the NVD entry. Maintainers and integrators must apply a source-level fix to send_diagnostic_request that enforces a length check before the memcpy, and rebuild dependent firmware. Track the miaofng/uds-c and OpenXC uds-c repositories for upstream remediation.

Workarounds

• Cap caller-supplied payload_length to MAX_DIAGNOSTIC_PAYLOAD_SIZE - 1 - pid_length in wrapper code that constructs UDS requests.
• Compile the library with -fstack-protector-strong, -D_FORTIFY_SOURCE=2, and non-executable stack flags to reduce exploitability.
• Enforce UDS message filtering at central gateway ECUs to drop frames whose advertised payload length exceeds the protocol-defined maximum for the requested service.

# Configuration example: hardened build flags for integrators rebuilding uds-c
CFLAGS="-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE -Wformat -Wformat-security"
LDFLAGS="-Wl,-z,relro -Wl,-z,now -pie"
make CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS"