Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[BUG] SIGSEGV in tlt_read_rcwt(): rcwt_loop re-checks parsebuf[6..7] after it was overwritten with caption data (608-mode RCWT)

オープン
  • 何か問題がありますか？
#2,429 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@VishnuSrivatsava がすでに取り組んでいます。

2026年10月27日 から。

  • #2430 @VishnuSrivatsava による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c
領域
backend, testing

調査の方向性

Start in src/lib_ccx/general_loop.c at rcwt_loop() and trace where parsebuf is reused after the RCWT header is validated. Reproduce with the 83-byte sample and ccextractor crash.rcwt, then check the 608-mode branch and teletext-mode behavior. Done when the crash is fixed and both modes retain their expected output; the issue reports local validation but does not name test files.

索引モデルが issue の本文から書いたものです。

説明

CCExtractor version: 0.96.5, git master d7eb132e (built from source on 2026-10-27)

In raising this issue, I confirm the following:

  • I have read and understood the contributors guide.
  • I have checked that the bug I am reporting can be replicated.
  • I have checked that this issue isn't already reported in closed issues and in open issues.
  • I have checked the pull requests tab for existing solutions/implementations.
  • I have verified this on current master built from source.

Necessary information

  • Is this a regression? No — the loop code involved dates back to 2015; I found it by code reading and confirmed it with AddressSanitizer.
  • What platform did you use? Mac (macOS arm64, Apple clang; the crashing code is platform-independent C).
  • What were the used arguments? ccextractor crash.rcwt

Video links

Additional information

Summary

rcwt_loop() (src/lib_ccx/general_loop.c) decides whether an RCWT input is a teletext file by testing parsebuf[6] == 0 && parsebuf[7] == 2 (the file-format revision bytes of the 11-byte header) at two places:

  1. Before the processing loop — correct, parsebuf still holds the file header.
  2. At the top of every loop iteration (line 1792 on master) — incorrect: in 608 mode parsebuf is reused for the 10-byte data header and then realloc'd and overwritten with the raw caption-block bytes.

If the caption byte stream contains 00 02 at offsets 6–7, iteration 2 takes the teletext branch even though the file is a 608-mode RCWT. In that mode dec_ctx->private_data is NULL (telxcc_init() only runs in teletext mode), so the branch calls tlt_read_rcwt(NULL, buf, dec_sub), which does memcpy(&(ctx->last_timestamp), &buf[1], sizeof(uint64_t)) (src/lib_ccx/telxcc.c:1327) → SIGSEGV.

00 02 at those offsets does not require a hand-crafted file: in RCWT caption blocks the bytes at positions 6–7 are raw CC data (e.g. a 00 marker byte followed by 02), which ordinary corruption or real caption content can produce.

Reproduction

$ base64 -d crash.rcwt.b64 > crash.rcwt
$ ccextractor crash.rcwt

Plain build on master d7eb132e: exit code 139 (SIGSEGV).

With an AddressSanitizer build:

==...==ERROR: AddressSanitizer: SEGV on unknown address 0x000000007700 (pc ... WRITE of size 8)
    #0 tlt_read_rcwt telxcc.c:1327
    #1 rcwt_loop general_loop.c:1801
    #2 start_ccx ccextractor.c:217

The PoC is a minimal 608-mode RCWT file: valid 11-byte header (CC CC ED, revision 00 01), a data header with cbcount = 3, caption blocks 04 80 80 04 80 80 00 02 80 (bytes 6–7 = 00 02), plus 53 bytes so the hijacked teletext branch actually runs the NULL-context memcpy.

Proposed fix

Decide the mode once, right after the header is validated:

is_teletext = (parsebuf[6] == 0 && parsebuf[7] == 2);

and test is_teletext (not parsebuf[6..7]) inside the loop. I have this implemented and validated locally (PoC exits cleanly; a teletext-mode RCWT produces byte-identical output before/after; a 12-sample TS corpus shows no behavior change). Happy to open a PR with the patch if you agree with the approach.

主要言語
C
スター
912
フォーク
598
平均マージ
2日 7時間
マージ済み PR（30日）
29

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CCExtractor/ccextractor のほかの issue

CCExtractor/ccextractor の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。