Hi iceray-Li duplicate: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24706 or i guess its this report
thx
On Sat, Sep 26, 2026 at 07:28:09PM +0800, iceray-Li wrote:
> Hello FFmpeg maintainers,
>
> Short version so this is easy to triage: this is not a security report and I
> am not asking for a CVE. The same hunk is already fixed on master by
> 4a511dc8 ("avcodec/h264dec: do not add 0 to the NULL plane pointers when
> filling a missing field", marked "Not a vulnerability"). I am writing because
> release/9.0 does not have that fix, and I would like to know whether a
> backport would be acceptable there.
>
> I hit it independently while fuzzing the H.264 decoder of the 9.0 release.
>
> ## What happens
>
> The decoder takes the "duplicate the missing field" recovery path in
> finalize_frame(). That path computes plane pointers for all four planes, but
> planes the pixel format does not use have f->data[p] == NULL and
> f->linesize[p] == 0, so the expression evaluates NULL + 0:
>
> libavcodec/h264dec.c:951:42: runtime error: applying zero offset to null
> pointer
> #0 finalize_frame libavcodec/h264dec.c:951:42
> #1 h264_decode_frame libavcodec/h264dec.c:1076:19
> #2 decode_simple_internal libavcodec/decode.c:457:16
> #3 decode_simple_receive_frame libavcodec/decode.c:617:15
> #4 ff_decode_receive_frame_internal libavcodec/decode.c:653:15
> #5 decode_receive_frame_internal libavcodec/decode.c:671:15
> #6 avcodec_send_packet libavcodec/decode.c:755:15
> #7 LLVMFuzzerTestOneInput tools/target_dec_fuzzer.c:576:25
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> libavcodec/h264dec.c:951:42 in
>
> Impact: sanitizer and CI builds abort. In an ordinary release build the
> expression has no observable effect, and I do not claim otherwise. I am also
> not claiming to be the first to find it - master's fix came from an OSS-Fuzz
> report (Fixes: irADzptPLJF2, Found-by: Qiang Li).
>
> ## Evidence
>
> - Harness: tools/target_dec_fuzzer built for the H.264 decoder, clang,
> -fsanitize=address,undefined, --disable-asm, on the 9.0 release sources
> (RELEASE and VERSION are both 9.0)
> - Input: ffmpeg_finalize_frame_h264dec_null_plus_zero.poc, 419 bytes,
> sha256 2058c244cc9e9af2aeb8d19ac8c3b5a332d7374294b1b018530f2d30e19b8bba
> - Before the patch the input aborts the 9.0 tree (exit code 1, the report
> above); with the patch applied the same input exits 0 with no diagnostic and
> is still decoded
>
> ## The fix, if you want it
>
> The attached patch is a plain cherry-pick of 4a511dc8 onto release/9.0 - only
> the hunk offset differs, because 9.0 has this code at line 951 instead of
> 1004.
> FF_PTR_ADD() returns the pointer unchanged for a zero offset, so no arithmetic
> is performed on NULL and the values passed to av_image_copy() are identical
> for
> every input. The only question I have is whether you want that on
> release/9.0, in the same way the similar 51c4a23d74a ("avcodec/opus/dec: only
> add offsets to valid channel pointers", same clang-ubsan null pointer symptom)
> was cherry-picked there on 2026-09-25.
>
> I have also opened it as a pull request with release/9.0 as the base, so you
> can review/merge/close it there directly:
>
> https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24706
>
> Happy to reroll it in whatever form you prefer. If a backport to release/9.0
> is not wanted, no action is needed from your side and I will consider this
> closed.
>
> Best regards,
> iceray-Li
> h264dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> eca8e4b12b55c10d7b31f9a9eaeda1bd5901c615
> /var0001-avcodec-h264dec-do-not-add-0-to-the-NULL-plane-point.patch
> From c2270420a20c8c9509ca9e15bccab9583fe5e6ce Mon Sep 17 00:00:00 2001
> From: Michael Niedermayer <[email protected]>
> Date: Sat, 19 Sep 2026 22:16:35 +0200
> Subject: [PATCH] avcodec/h264dec: do not add 0 to the NULL plane pointers when
> filling a missing field
>
> Not a vulnerability
>
> Fixes: irADzptPLJF2
> Found-by: Qiang Li <[email protected]>
> (cherry picked from commit 4a511dc8eba349b43817e49661b28d521c6b604a)
> Signed-off-by: iceray <[email protected]>
> ---
> libavcodec/h264dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ca65df2b84e..1f055345c2b 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -948,8 +948,8 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
> H264Picture *out, int *g
> av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill
> missing\n", field);
>
> for (p = 0; p<4; p++) {
> - dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
> - src_data[p] = f->data[p] + field *f->linesize[p];
> + dst_data[p] = FF_PTR_ADD(f->data[p],
> (field^1)*f->linesize[p]);
> + src_data[p] = FF_PTR_ADD(f->data[p], field
> *f->linesize[p]);
> linesizes[p] = 2*f->linesize[p];
> }
>
> --
> 2.25.1
>
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
