From 6c6dc2b1140faef7eed12716a1a775dd3b0171a6 Mon Sep 17 00:00:00 2001 From: "russell@unturf.com" Date: Tue, 31 Mar 2026 21:33:22 -0400 Subject: [PATCH] =?UTF-8?q?x264+x265:=205-MOAD=20scan=20CLEAN=20=E2=80=94?= =?UTF-8?q?=20all=20MOADs=20checked,=20no=20defects=20found?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- defects/x264-scan/CLEAN.md | 46 +++++++++++++++++++++++++++++ defects/x265-scan/CLEAN.md | 59 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 defects/x264-scan/CLEAN.md create mode 100644 defects/x265-scan/CLEAN.md diff --git a/defects/x264-scan/CLEAN.md b/defects/x264-scan/CLEAN.md new file mode 100644 index 000000000..5b61d860c --- /dev/null +++ b/defects/x264-scan/CLEAN.md @@ -0,0 +1,46 @@ +# x264 — 5-MOAD Scan Result: CLEAN + +Scanned: 2026-03-31 +Repo: https://code.videolan.org/videolan/x264.git (depth=1) +Language: C + +## MOAD-0001 (CWE-407): CLEAN + +x264 is a pure H.264 video encoder. All collection scans over reference frame lists +and motion vector candidate lists are bounded by codec-spec constants: + +- `X264_REF_MAX` = 16 reference frames maximum (H.264 spec limit) +- `i_mvc` (MV predictor candidates): bounded by spatial neighbor count (~4) +- `x264_predictor_clip()` in `common/common.h`: single O(N) pass over MV candidates, + deduplicates only against `pmv` (one value), not against each other +- `analyse_weight_frame()` in `encoder/analyse.c`: O(R^2) inner weight plane scaling + but R is bounded by `X264_REF_MAX` = 16, making it O(256) constant +- `ratecontrol.c` nested loops: outer over `num_entries` (frames), inner over `cplxblur` + window (fixed ~20 frames) = O(F * 20), not O(F^2) +- Reference list reorder check in `encoder/encoder.c`: O(R) per list, R <= 16 + +No unbounded O(N^2) list membership patterns found. + +## MOAD-0002 (Intertangle): CLEAN + +`x264_t` is a per-encoder context struct passed explicitly to all functions. No global +mutable singleton state is shared across encoder instances. Each thread in frame-parallel +mode gets its own `x264_t` slice context. No god object anti-pattern. + +## MOAD-0003 (Leaked Context): CLEAN + +No ThreadLocal / `__thread` / `pthread_key` usage found. x264 is C-based and uses +explicit context passing via `x264_t*`. No request-scoped identity carried on thread. + +## MOAD-0004 (CWE-312 Logged Secret): CLEAN + +x264 is a pure codec library with no authentication, credential, or token data flows. +`x264_log()` calls log encoder state, frame type decisions, and file path errors. +No credential exposure possible. File paths logged in error cases do not contain auth tokens +(codec CLIs do not accept `rtsp://user:pass@host` style input natively). + +## MOAD-0005 (Thundering Herd): CLEAN + +x264 frame allocation uses `x264_frame_pop_unused()` from a pre-allocated pool, called +under `x264_encoder_encode()` which is documented as not thread-safe (caller serializes). +No concurrent get+null+compute+put cache pattern. diff --git a/defects/x265-scan/CLEAN.md b/defects/x265-scan/CLEAN.md new file mode 100644 index 000000000..197d572f8 --- /dev/null +++ b/defects/x265-scan/CLEAN.md @@ -0,0 +1,59 @@ +# x265 (libx265 / HEVC Reference Encoder) — 5-MOAD Scan Result: CLEAN + +Scanned: 2026-03-31 +Repo: https://github.com/videolan/x265 (depth=1) +Language: C++ + +## MOAD-0001 (CWE-407): CLEAN + +x265 is a pure H.265/HEVC video encoder. All hot-path collection scans are bounded +by HEVC spec constants: + +- `m_numRefIdx[list]` bounded by `MAX_NUM_REF` = 16 (HEVC spec) +- `RPS::sortDeltaPOC()` in `common/slice.cpp`: insertion sort over `numberOfPictures` + (max 16 entries per HEVC spec) — O(16^2) = constant 256 comparisons, never O(N^2) at scale +- `DPB::applyReferencePictureSet()` in `encoder/dpb.cpp`: O(F * R) where F = DPB frames + (bounded by `maxDecPicBuffer` <= 16) and R = RPS size (<= 16) — O(256) constant +- `DPB::computeRPS()`: single O(F) pass over DPB linked list, F bounded by 16 +- `MotionEstimate` candidate dedup in `encoder/motion.cpp` line 800: O(C) pass over + candidates where C is small (4-8 spatial neighbors); no inner O(C) membership scan +- `RateControl::getZone()` in `encoder/ratecontrol.cpp`: O(Z) scan over user-defined + zones, called ~4 times per frame. O(F * Z) total, not O(F^2) or O(Z^2). + Called in the RC path (not motion estimation inner loop); Z is typically small (< 100 + for VOD workflows). Borderline, not a confirmed CWE-407 — the zone scan is not + inside a per-element inner loop. +- `Analysis::findSameContentRefCount()` in `encoder/analysis.cpp`: O(2 * R) where + R = numRefIdx, bounded by 16 + +No unbounded O(N^2) list membership patterns found in hot encode path. + +## MOAD-0002 (Intertangle): CLEAN + +`Encoder` in `encoder/encoder.h` is a per-encoder instance object. Each `x265_encoder` +opaque pointer wraps a single `Encoder` instance. Frame encoders (`FrameEncoder`) are +worker objects coordinated through `ThreadPool`. No global singleton shared mutable state +between independent encoder instances. + +## MOAD-0003 (Leaked Context): CLEAN + +`ThreadLocalData` in `encoder/analysis.h` is per-CTU-row work state: it holds +`Analysis` objects and scratch buffers scoped to one frame-encoding row. It carries +no request-scoped identity (user ID, session token, tenant context). It is not a +ThreadLocal in our MOAD-0003 sense — it is work state, not identity. + +## MOAD-0004 (CWE-312 Logged Secret): CLEAN + +x265 is a pure codec library with no authentication or credential data flows. +`x265_csvlog_encode()` in `encoder/api.cpp` writes `argv[]` to a CSV file — this +dumps CLI arguments including filenames. Input filenames could theoretically contain +embedded credentials (`rtsp://user:pass@host/stream`) but this is a codec CLI +convention issue, not a logging defect in our library code. The output goes to +a CSV file, not a centralized log stream. Not a MOAD-0004 finding. + +## MOAD-0005 (Thundering Herd): CLEAN + +`x265_encoder_encode()` is documented as not thread-safe per-encoder-instance. +Our frame free-list access (`m_dpb->m_freeList`) occurs under this single-threaded +API entry contract — no concurrent get+null+compute+put pattern. Frame-level +parallelism is internal to the encoder with proper `Lock`/`atomic` primitives +(`m_sliceQpLock`, `m_sliceRefIdxLock`, etc. in `encoder/encoder.h`).