RT-Thread / RT-Thread/rt-thread

Static buffer overflow in RT-Thread rt-link utility

Open
#8,289 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
12.2k
Forks
5.4k
Avg merge
4d 12h
Merged PRs (30d)
40

Description

Hi,

I would like to report another potential vulnerability in the current version of RT-Thread. Please let me know if you plan to ask for a CVE ID in case the vulnerability is confirmed. I'm available if you need further clarifications.

Potential static buffer overflow in RT-Thread rt-link utility

Summary

I spotted a potential static buffer overflow vulnerability at the following location in the RT-Thread rt-link utility source code:
https://github.com/RT-Thread/rt-thread/blob/master/components/utilities/rt-link/src/rtlink.c#L239

Details

Lack of length check in the frame_send() function could lead to a static buffer overflow at the marked line:

static rt_ssize_t frame_send(struct rt_link_frame *frame)
{
    rt_size_t length = 0;
    rt_uint8_t *data = RT_NULL;

    rt_memset(rt_link_scb->sendbuffer, 0, sizeof(rt_link_scb->sendbuffer));
    data = rt_link_scb->sendbuffer;
    length = RT_LINK_HEAD_LENGTH;
    if (frame->head.crc)
    {
        length += RT_LINK_CRC_LENGTH;
    }
    if (frame->head.extend)
    {
        length += RT_LINK_EXTEND_LENGTH;
    }

    length += frame->data_len;
    frame->head.length = frame->data_len;
    rt_memcpy(data, &frame->head, RT_LINK_HEAD_LENGTH);
    data = data + RT_LINK_HEAD_LENGTH;
    if (frame->head.extend)
    {
        rt_memcpy(data, &frame->extend, RT_LINK_EXTEND_LENGTH);
        data = data + RT_LINK_EXTEND_LENGTH;
    }
    if (frame->attribute == RT_LINK_SHORT_DATA_FRAME || frame->attribute == RT_LINK_LONG_DATA_FRAME)
    {
        rt_memcpy(data, frame->real_data, frame->data_len); /* VULN: static buffer overflow, if frame->data_len > 1024 - 4 (it's a rt_uint16_t so at least in theory can be up to 65535) */
        data = data + frame->data_len;
    }
    if (frame->head.crc)
    {
        frame->crc = rt_link_scb->calculate_crc(RT_FALSE, rt_link_scb->sendbuffer, length - RT_LINK_CRC_LENGTH);
        rt_memcpy(data, &frame->crc, RT_LINK_CRC_LENGTH);
    }

    LOG_D("frame send seq(%d) len(%d) attr:(%d), crc:(0x%08x).", frame->head.sequence, length, frame->attribute, frame->crc);
    return rt_link_hw_send(rt_link_scb->sendbuffer, length);
}
Impact

If the unchecked input above is confirmed to be attacker-controlled and crossing a security boundary, the impact of the reported buffer overflow vulnerability could range from denial of service to arbitrary code execution.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in components/utilities/rt-link/src/rtlink.c at the frame_send() code around line 239, then trace callers to determine how frame->data_len and frame->real_data are populated. Verify the send-buffer capacity and whether the length can be attacker-controlled; done means confirming or disproving the overflow and documenting or addressing the result with appropriate validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.