prevent heap buffer overflow in Teletext demux path

[THE-Amrit-mahto-05]

[FIX] Prevent heap buffer overflow in Teletext demux path

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 have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

Summary

This pull request fixes a heap buffer overflow in the Teletext demux path
(CCX_CODEC_TELETEXT) in the function copy_capbuf_demux_data
in src/lib_ccx/ts_functions.c.

Details

Previously, the code copied cinfo->capbuf into the destination buffer
without verifying that there was enough space remaining:

memcpy(ptr->buffer + ptr->len, cinfo->capbuf, cinfo->capbuflen);

If capbuflen exceeded the remaining buffer space, this caused a heap
buffer overflow, potentially leading to memory corruption or crash.

The generic PES/DVB path already performed a bounds check, but the
Teletext path was missing this validation.

Fix
A bou
nds check is added before copying the Teletext data:

if (cinfo->capbuflen > BUFSIZE - ptr->len) {
    fatal(CCX_COMMON_EXIT_BUG_BUG,
          "Teletext packet (%ld) larger than remaining buffer (%lld).\n",
          cinfo->capbuflen, BUFSIZE - ptr->len);
}
memcpy(ptr->buffer + ptr->len, cinfo->capbuf, cinfo->capbuflen);
ptr->len += cinfo->capbuflen;

Fixes #1933

[cfsmp3]

Thanks for this security fix! The bounds check is correct and necessary - the teletext path was indeed missing validation that the PES/DVB paths already had.

However, please fix the format specifiers before we can merge:

1. capbuflen is int64_t, so use PRId64 instead of %ld:

   #include <inttypes.h>
   // ...
   fatal(CCX_COMMON_EXIT_BUG_BUG,
         "Teletext packet (%" PRId64 ") larger than remaining buffer (%" PRId64 ").\n",
         cinfo->capbuflen, (int64_t)(BUFSIZE - ptr->len));

2. Cast BUFSIZE - ptr->len to int64_t since the subtraction involves size_t which is platform-dependent.

We're trying to avoid platform-dependent types like size_t in user-facing output and use explicit fixed-width types (int64_t, uint32_t, etc.) where possible for consistency across platforms.

Once you make these changes, we'll be ready to merge. Thanks!

[THE-Amrit-mahto-05]

@cfsmp3
Thanks for the review and the guidance.

I’ve updated the code to:
Use PRId64 instead of %ld for capbuflen
Cast (BUFSIZE - ptr->len) to int64_t to avoid platform-dependent size_t in user-facing output
The changes are now pushed. Please let me know if anything else needs adjustment.

Thanks again!

[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 64ce4ac...:

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

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 64ce4ac...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	7/7
DVD	3/3
DVR-MS	2/2
General	27/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

NOTE: The following tests have been failing on the master branch as well as the PR:

• ccextractor --out=spupng c83f765c66..., Last passed:

  Test 7465

• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed:

  Test 7465

• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed:

  Test 7465

• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed:

  Test 7465

• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed:

  Test 7465

• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed:

  Test 7465

Congratulations: Merging this PR would fix the following tests:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., Last passed: Never

This PR does not introduce any new test failures. However, some tests are failing on both master and this PR (see above).

Check the result page for more info.