[BUG] Integer overflow in ccxr_process_cc_data(): cc_count * 3 overflows i32 on malformed input

[NexionisJake]

Summary

ccxr_process_cc_data() in src/rust/src/lib.rs computes cc_count * 3
using i32 arithmetic with no upper-bound check on cc_count. A malformed
media file declaring a large cc_count (> i32::MAX / 3, i.e. > ~715 million)
causes integer overflow. In debug builds this is an unconditional panic. In
release builds it wraps around silently, producing an empty range and
discarding all CC data for that frame.

Location

src/rust/src/lib.rs — ccxr_process_cc_data(), line ~415

Code

let mut cc_data: Vec<u8> = (0..cc_count * 3)
    .map(|x| unsafe { *data.add(x as usize) })
    .collect();

cc_count arrives from C as i32. There is a <= 0 check but no upper bound.

Impact

• Debug builds: panic crash on any input with large cc_count
• Release builds: silent data loss / wrong output with no error message
• Triggerable from any malformed or adversarially crafted media file

Suggested Fix

Cast to usize before the multiplication and add an upper-bound guard:

const MAX_CC_COUNT: usize = 1024; // or a reasoned project-appropriate limit

let cc_count_usize = cc_count as usize;
if cc_count_usize > MAX_CC_COUNT {
    return -1;
}

let mut cc_data: Vec<u8> = (0..cc_count_usize * 3)
    .map(|x| unsafe { *data.add(x) })
    .collect();

Environment

• Debug builds: panic on overflow
• Release builds: silent wrap-around
• Triggerable from malformed MP4/TS with crafted CC data