[BUG] `avc_ctx->cc_count` is `uint8_t`/`u8`, wrapping around when H.264 access units accumulate multiple SEIs beyond 255 triplets
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 62/100
Hướng nghiên cứu
The counter is declared as unsigned char cc_count in src/lib_ccx/avc_functions.h and updated in copy_ccdata_to_buffer in src/lib_ccx/avc_functions.c, and the Rust mirror is the u8 field in src/rust/src/avc/common_types.rs. Start by reading copy_ccdata_to_buffer to see how cc_count indexes the buffer and what the MAX_CC_COUNT and HDCC_MAX_TRIPLETS_PER_SLOT limits assume. Done means the count type can hold 310 triplets on both sides, the two definitions agree, and the buffer bounds check still holds.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
CCExtractor version: master (post-#2359 / commit c1043ca7)
Necessary information
- Is this a regression (i.e. did it work before)? NO
- What platform did you use? All (Linux / macOS / Windows)
- What were the used arguments? Standard H.264 / MPEG-TS extraction (
ccextractor input.ts)
Summary
In commit c1043ca7 (#2359), MAX_CC_COUNT and HDCC_MAX_TRIPLETS_PER_SLOT were raised from 31 to 310 so that H.264 access units carrying multiple SEI messages can buffer all their caption triplets without discarding the frame.
However, avc_ctx->cc_count is typed as unsigned char in C (src/lib_ccx/avc_functions.h:6) and u8 in Rust (src/rust/src/avc/common_types.rs:7). Because an 8-bit unsigned integer caps out at 255, the buffer accumulator wraps around whenever an access unit carries dense or multiple SEI packets totaling between 256 and 310 triplets.
Root Cause Analysis
1. In C (src/lib_ccx/avc_functions.c:442-453):
struct avc_ctx
{
unsigned char cc_count; // <--- uint8_t: range 0..255
unsigned char *cc_data;
...
};
void copy_ccdata_to_buffer(struct avc_ctx *ctx, char *source, int new_cc_count)
{
...
memcpy(ctx->cc_data + ctx->cc_count * 3, source, new_cc_count * 3 + 1);
ctx->cc_count += new_cc_count; // <--- Wraps modulo 256 on overflow
ctx->cc_buffer_saved = CCX_FALSE;
}
- Ngôn ngữ chính
- C
- Star
- 908
- Fork
- 595
- Merge trung bình
- 3 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 31
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của CCExtractor/ccextractor
-
[BUG] Heap buffer overflow in parse_PMT with C0/C1 section lengthCó thể đã có người làm @kun-codes đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
CCExtractor/ccextractor#2419 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Filename sequence expansion (`+`) panics on numeric values exceeding `i32::MAX`Có thể đã có người làm @muntasir-396 đã nhận 4 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
CCExtractor/ccextractor#2402 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[PROPOSAL] Port the MythTV packet reader (myth.c) to RustCó thể đã có người làm @kaihere14 đã nhận 1 ngày trước. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
CCExtractor/ccextractor#2421 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
CCExtractor: stack out-of-bounds write and quadratic out-of-bounds read in the DVB subtitle descriptor parser (parse_dvb_description)Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
CCExtractor/ccextractor#2417 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] --out=report: heap-use-after-free in process608(), and a crash with more than one input fileCó thể đã có người làm @Deepak-negi11 đã nhận 3 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
CCExtractor/ccextractor#2412 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của CCExtractor/ccextractor
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100
FriendsofECCE/ECCE#519 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
containers/crun#2415 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bluetooth: Controller: memcpy() with NULL source in HCI extended and periodic reportsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
zephyrproject-rtos/zephyr#123423 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày