[PR #1953] Fix/ts heap overflow #2758

New Issue

claunia · 2026-01-29T17:23:46Z

claunia commented

2026-01-29 17:23:46 +00:00

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1953

State: closed
Merged: Yes

[FIX]

In raising this pull request, I confirm the following (please check boxes):

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
I give this submission freely, and claim no ownership to its content.
I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

I absolutely love CCExtractor, but have not contributed previously.
I am an active contributor to CCExtractor.

Description

Component: Transport Stream (TS) handling
File: src/lib_ccx/ts_functions.c
Function: copy_payload_to_capbuf

The Problem

The function copy_payload_to_capbuf grows a capture buffer using:

newcapbuflen = cinfo->capbuflen + payload->length;

However, there was no check for integer overflow before this addition.
If a very large payload->length is combined with capbuflen, the sum can wrap around, resulting in a very small allocation passed to realloc.
This can cause a heap buffer overflow, potentially crashing the program or corrupting memory.

The Proposed Fix

Promoted the newcapbuflen variable to int64_t to handle large sums safely.
Added an explicit overflow guard:

if (payload->length > INT64_MAX - cinfo->capbuflen)
{
    mprint("Error: capbuf size overflow\n");
    return -1;
}

Ensured safe allocation using size_t in the realloc call.
Logged errors and returned safely if allocation fails.

Impact

Prevents heap memory corruption.
Prevents crashes caused by malformed TS data.
Maintains normal functionality for valid input.

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1953 **State:** closed **Merged:** Yes ---  **[FIX]** **In raising this pull request, I confirm the following (please check boxes):** - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that another pull request for this purpose does not exist. - [x] I have considered, and confirmed that this submission will be valuable to others. - [x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [x] I give this submission freely, and claim no ownership to its content. - [x] I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT). **My familiarity with the project is as follows (check one):** - [ ] I absolutely love CCExtractor, but have not contributed previously. - [x] I am an active contributor to CCExtractor. --- ### Description Component: Transport Stream (TS) handling File: src/lib_ccx/ts_functions.c Function: copy_payload_to_capbuf ### The Problem The function `copy_payload_to_capbuf` grows a capture buffer using: ```c newcapbuflen = cinfo->capbuflen + payload->length; ``` However, there was no check for integer overflow before this addition. If a very large payload->length is combined with capbuflen, the sum can wrap around, resulting in a very small allocation passed to realloc. This can cause a heap buffer overflow, potentially crashing the program or corrupting memory. ### The Proposed Fix - Promoted the newcapbuflen variable to int64_t to handle large sums safely. - Added an explicit overflow guard: ```c if (payload->length > INT64_MAX - cinfo->capbuflen) { mprint("Error: capbuf size overflow\n"); return -1; } ``` - Ensured safe allocation using size_t in the realloc call. - Logged errors and returned safely if allocation fails. ### Impact - Prevents heap memory corruption. - Prevents crashes caused by malformed TS data. - Maintains normal functionality for valid input.

claunia added the pull-request label 2026-01-29 17:23:46 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2758