Fix/ts heap overflow

[THE-Amrit-mahto-05]

[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.

[cfsmp3]

Thanks for working on these security fixes! The overflow checks are a good approach. However, I found an issue that needs to be fixed:

Bug in ts_functions.c

The casts to (int) are incorrect:

cinfo->capbufsize = (int)newcapbuflen; // Note: capbufsize is int in struct cap_info
cinfo->capbuflen = (int)newcapbuflen;  // Note: capbuflen is int in struct cap_info

The struct definition in ccx_demuxer.h shows these fields are actually int64_t:

int64_t capbufsize;  // line 59
int64_t capbuflen;   // line 61

The (int) casts will truncate 64-bit values to 32-bit, which could cause bugs. Please remove the casts:

cinfo->capbufsize = newcapbuflen;
cinfo->capbuflen = newcapbuflen;

Missing CHANGES.TXT entry

Please add an entry to docs/CHANGES.TXT documenting these security fixes.

Note about related PRs

Since this PR includes all the commits from #1951 and #1949, I'll close those as superseded once this is merged.

---

The EIA-608 and ISDB-CC fixes look good! Just need the TS fix corrected.

[THE-Amrit-mahto-05]

@cfsmp3

Thanks for the detailed review!

I’ve addressed all the requested changes:

Removed the incorrect (int) casts and now assign newcapbuflen directly to capbufsize and capbuflen (both int64_t as defined in ccx_demuxer.h).

Added the security fix entries to docs/CHANGES.TXT documenting the Teletext and Transport Stream overflow fixes.

The remaining checks are currently running. Please let me know if you’d like any further adjustments once CI completes.

[ccextractor-bot]

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 3529bb2...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	7/7
DVD	3/3
DVR-MS	2/2
General	25/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	81/86
Teletext	21/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

[ccextractor-bot]

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 3529bb2...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	6/7
DVD	3/3
DVR-MS	2/2
General	25/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	80/86
Teletext	21/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• ccextractor --out=spupng c83f765c66...
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

[cfsmp3]

Thanks for the quick fix! The casts are removed and CHANGES.TXT is updated.

Build passes, tests show no regression.

Minor note: The comments still say "capbufsize is int" but the struct uses int64_t - not a blocker, just FYI.

Approving and merging.

[cfsmp3]

@THE-Amrit-mahto-05 I've merged this, but TBH, since we're migrating to Rust, I don't think it's worth spending time on these things, particularly if they are purely theoretical problems...