starred/ccextractor
1
0
Fork 0
mirror of https://github.com/CCExtractor/ccextractor.git synced 2026-02-03 21:23:48 +00:00
Code Issues 1.5k Packages Projects Releases 20 Wiki Activity

[Bug] Heap-buffer-overflow in parse_PAT #907

New Issue
Closed
opened 2026-01-29 16:56:38 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 16:56:38 +00:00
Owner
Copy Link

Originally created by @oneafter on GitHub (Jan 23, 2026).

Description

We discovered a Heap-buffer-overflow vulnerability in ccextractor. The crash occurs in the parse_PAT function when processing a malformed MPEG-TS file.

The ASAN report indicates a READ violation of size 1, occurring 22 bytes past the end of a 184-byte allocated region (standard TS payload buffer).

Environment

  • OS: Linux x86_64
  • Complier: Clang
  • Build Configuration: Release mode with ASan enabled.

Vulnerability Details

  • Target: CCExtractor
  • Vulnerability Type: CWE-125: Out-of-bounds Read
  • Function: parse_PAT
  • Location: src/lib_ccx/ts_tables.c:624
  • Root Cause Analysis: The buffer is allocated in ts_buffer_psi_packet with a size of 184 bytes (typical TS packet size). The function parse_PAT parses the Program Association Table. It reads a section_length from the data headers and iterates through the buffer.
// Example logic in parse_PAT
while (processed_bytes < section_length) {
    // Reads data from payload...
}

If the input file specifies a section_length that extends beyond the actual 184-byte buffer limit, and there is no boundary check against the actual buffer size, the parser reads into adjacent heap memory.

Reproduce

  1. Build ccextractor with Release optimization and ASAN enabled.
  2. Run with the crashing file:
./build/ccextractor repro
ASAN report 
==2633==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x510000000b0e at pc 0x55c9f2fbda46 bp 0x7fffaf1981d0 sp 0x7fffaf1981c8
READ of size 1 at 0x510000000b0e thread T0
    #0 0x55c9f2fbda45 in parse_PAT /src/ccextractor/src/lib_ccx/ts_tables.c:624:19
    #1 0x55c9f2fad3f7 in ts_readstream /src/ccextractor/src/lib_ccx/ts_functions.c:796:5
    #2 0x55c9f2fb0e1d in ts_get_more_data /src/ccextractor/src/lib_ccx/ts_functions.c:1092:9
    #3 0x55c9f2f58b59 in general_loop /src/ccextractor/src/lib_ccx/general_loop.c:1374:9
    #4 0x55c9f2c2f2c3 in start_ccx /src/ccextractor/src/ccextractor.c:195:11
    #5 0x7f1da51011c9  (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #6 0x7f1da510128a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #7 0x55c9f29f0404 in _start (/src/ccextractor/build_afl/ccextractor+0xf2404) (BuildId: 144afa46e860f46ef2c26b7a110ecb6056d5f015)

0x510000000b0e is located 22 bytes after 184-byte region [0x510000000a40,0x510000000af8)
allocated by thread T0 here:
    #0 0x55c9f2a90233 in malloc (/src/ccextractor/build_afl/ccextractor+0x192233) (BuildId: 144afa46e860f46ef2c26b7a110ecb6056d5f015)
    #1 0x55c9f2fbbbf8 in ts_buffer_psi_packet /src/ccextractor/src/lib_ccx/ts_tables.c:563:46

SUMMARY: AddressSanitizer: heap-buffer-overflow /src/ccextractor/src/lib_ccx/ts_tables.c:624:19 in parse_PAT
Shadow bytes around the buggy address:
  0x510000000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x510000000900: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x510000000980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
  0x510000000a00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x510000000a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
=>0x510000000b00: fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x510000000b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x510000000c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x510000000c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x510000000d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x510000000d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2633==ABORTING
Originally created by @oneafter on GitHub (Jan 23, 2026). ### Description We discovered a Heap-buffer-overflow vulnerability in ccextractor. The crash occurs in the parse_PAT function when processing a malformed MPEG-TS file. The ASAN report indicates a READ violation of size 1, occurring 22 bytes past the end of a 184-byte allocated region (standard TS payload buffer). ### Environment - OS: Linux x86_64 - Complier: Clang - Build Configuration: Release mode with ASan enabled. ### Vulnerability Details - Target: CCExtractor - Vulnerability Type: CWE-125: Out-of-bounds Read - Function: parse_PAT - Location: src/lib_ccx/ts_tables.c:624 - Root Cause Analysis: The buffer is allocated in ts_buffer_psi_packet with a size of 184 bytes (typical TS packet size). The function parse_PAT parses the Program Association Table. It reads a section_length from the data headers and iterates through the buffer. ``` // Example logic in parse_PAT while (processed_bytes < section_length) { // Reads data from payload... } ``` If the input file specifies a section_length that extends beyond the actual 184-byte buffer limit, and there is no boundary check against the actual buffer size, the parser reads into adjacent heap memory. ### Reproduce 1. Build ccextractor with Release optimization and ASAN enabled. 2. Run with the crashing [file](https://github.com/oneafter/0123/blob/main/cc1/repro): ``` ./build/ccextractor repro ``` <details> <summary>ASAN report</summary> ``` ==2633==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x510000000b0e at pc 0x55c9f2fbda46 bp 0x7fffaf1981d0 sp 0x7fffaf1981c8 READ of size 1 at 0x510000000b0e thread T0 #0 0x55c9f2fbda45 in parse_PAT /src/ccextractor/src/lib_ccx/ts_tables.c:624:19 #1 0x55c9f2fad3f7 in ts_readstream /src/ccextractor/src/lib_ccx/ts_functions.c:796:5 #2 0x55c9f2fb0e1d in ts_get_more_data /src/ccextractor/src/lib_ccx/ts_functions.c:1092:9 #3 0x55c9f2f58b59 in general_loop /src/ccextractor/src/lib_ccx/general_loop.c:1374:9 #4 0x55c9f2c2f2c3 in start_ccx /src/ccextractor/src/ccextractor.c:195:11 #5 0x7f1da51011c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) #6 0x7f1da510128a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) #7 0x55c9f29f0404 in _start (/src/ccextractor/build_afl/ccextractor+0xf2404) (BuildId: 144afa46e860f46ef2c26b7a110ecb6056d5f015) 0x510000000b0e is located 22 bytes after 184-byte region [0x510000000a40,0x510000000af8) allocated by thread T0 here: #0 0x55c9f2a90233 in malloc (/src/ccextractor/build_afl/ccextractor+0x192233) (BuildId: 144afa46e860f46ef2c26b7a110ecb6056d5f015) #1 0x55c9f2fbbbf8 in ts_buffer_psi_packet /src/ccextractor/src/lib_ccx/ts_tables.c:563:46 SUMMARY: AddressSanitizer: heap-buffer-overflow /src/ccextractor/src/lib_ccx/ts_tables.c:624:19 in parse_PAT Shadow bytes around the buggy address: 0x510000000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x510000000900: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x510000000980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 0x510000000a00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x510000000a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa =>0x510000000b00: fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x510000000b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x510000000c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x510000000c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x510000000d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x510000000d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2633==ABORTING ``` </details>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
CEA-708
difficulty: easy
difficulty: hard
difficulty: medium
DTMB
DVB
enhancement
enhancement
Flutter GUI
GCI19
good-first-task
GSoC 2021
GSOC-2023
GSOC-2023
GSOC-2023
GSoC-related
Hacktoberfest
HardsubX
help wanted
invalid
JokerTV
Mac / OSX
more-info-needed
needs-commercial-sponsor
needs-commercial-sponsor
needs-commercial-sponsor
needs-confirmation-of-being-broken
OCR
pull-request
Mirrored from GitHub Pull Request
 Python
regression
Rust
teletext
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#907
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?