Builder ffmpegsos-solaris10-i386 Build #13938

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpegsos-solaris10-i386' triggered this build

Steps and Logfiles:

1. git update ( 6 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 11 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 1 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 2 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Franciszek Kalinowski

   franek.kalinowskiohnoyoudont@isec.pl

Timing:

All Changes:

:

1. Change #268258

   Category	ffmpeg
   Changed by	Franciszek Kalinowski <franek.kalinowskiohnoyoudont@isec.pl>
   Changed at	Mon 25 May 2026 15:16:03
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	c79dfd29e6afca56294395be843d98d10858a7fa

   Comments

   avcodec/h264_slice: guard color_frame() against chroma-width underflow
   In the >= 9 bit path, color_frame() does
   `av_memcpy_backptr(dst + 2, 2, bytes - 2)`. When the effective chroma width
   is 1 pixel (bytes == 1) the count becomes -1 and the underlying fill16()
   loop runs roughly 2^32 times, producing a heap overflow. The original count
   was also wrong in units (pixels rather than bytes); fix that at the same
   time so the 2-pixel case still fills both pixels.
   
   Confirmed via a standalone harness reproducing av_memcpy_backptr's fill16
   loop with cnt = -1; reaching the call from a crafted H.264 bitstream
   requires Hi10P plus a frame_num gap on a frame whose effective chroma width
   is 1 pixel, which is hard to express but is reachable via mid-stream SPS
   changes. Compiles cleanly; no regressions seen running existing crafted
   H.264 PoCs and trivial transcodes.
   
   Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.

   Changed files

   • libavcodec/h264_slice.c