avcodec/h264_slice: reject slice_num >= 0xFFFF

An H.264 picture with 65536 slices makes slice_num collide with the
slice_table sentinel. slice_table is uint16_t, initialized via
memset(..., -1, ...) so spare entries (one per row, mb_stride =
mb_width + 1) stay 0xFFFF. slice_num is an uncapped ++h->current_slice.
At slice 65535 the collision makes slice_table[spare] == slice_num
pass, defeating the deblock_topleft check in xchg_mb_border and the
top_type zeroing in fill_decode_caches.

With both guards bypassed at mb_x = 0, top_borders[top_idx][-1]
underflows 96 bytes and XCHG writes at -88 below the allocation
(plus -72 and -56 for chroma in the non-444 path).

Fixes: heap-buffer-overflow

Found-by: Nicholas Carlini <nicholas@carlini.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 39e1969303)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit is contained in:
Nicholas Carlini
2026-03-14 04:47:53 +00:00
committed by Michael Niedermayer
parent 5bc4a9898c
commit a5696b44a6

View File

@@ -1979,6 +1979,12 @@ static int h264_slice_init(H264Context *h, H264SliceContext *sl,
h->ps.pps->chroma_qp_index_offset[1]) +
6 * (h->ps.sps->bit_depth_luma - 8);
// slice_table is uint16_t initialized to 0xFFFF as a sentinel.
if (h->current_slice >= 0xFFFE) {
av_log(h->avctx, AV_LOG_ERROR, "Too many slices (%d)\n", h->current_slice + 1);
return AVERROR_PATCHWELCOME;
}
sl->slice_num = ++h->current_slice;
if (sl->slice_num)