Security Fix : Buffer Overflow in Single Frame Transmission

[KIMDONGYEON00]

Summary

A buffer overflow vulnerability exists in isotp_send_single_frame function that relies only on assert() for size validation, which is disabled in release builds. This is the same pattern that caused a CVE in Zephyr RTOS ISO-TP implementation.

Zephyr CVE Reference

Zephyr RTOS had the exact same vulnerability pattern that was recently patched:
https://nvd.nist.gov/vuln/detail/CVE-2023-3725
GHSA-2g3m-p6c7-8rr3
Before (vulnerable):

__ASSERT_NO_MSG(len <= ISOTP_CAN_DL - index);
memcpy(&frame.data[index], data, len);

After (Fixed):

if (len > ISOTP_CAN_DL - index) {
    LOG_ERR("SF len does not fit DL");
    return -ENOSPC;
}
memcpy(&frame.data[index], data, len);

Affected Code in isotp-c

File: isotp.c Function: isotp_send_single_frame

static int isotp_send_single_frame(IsoTpLink* link, uint32_t id) {
    // ...
    assert(link->send_size <= 7);  // ONLY DEBUG-TIME PROTECTION
    memcpy(message.as.single_frame.data, link->send_buffer, link->send_size);
    // ...
}

Vulnerability Details

1. Debug-only protection
2. Buffer overflow risk

Impact

1. Memory corruption
2. System crashes

Recommended Fix

static int isotp_send_single_frame(IsoTpLink* link, uint32_t id) {

    IsoTpCanMessage message;
    int ret;
    
    /* multi frame message length must greater than 7  */
    if (link->send_size > 7) {
        return ISOTP_RET_OVERFLOW;
    }

    /* multi frame message length must greater than 7  */
    assert(link->send_size <= 7);
   // ...
}

Priority

High - Same pattern that warranted CVE in Zephyr RTOS

PoC

Due to the complexity of setting up a CAN hardware environment, I haven't tested this vulnerability against a real embedded system.
However, code analysis clearly demonstrates the buffer overflow potential.