[Bug 737412] New: h264: playing a certain broken stream causes a crash (stack corruption caused by codec parser)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=737412
  GStreamer | gst-plugins-bad | 1.4.3

           Summary: h264: playing a certain broken stream causes a crash
                    (stack corruption caused by codec parser)
    Classification: Platform
           Product: GStreamer
           Version: 1.4.3
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bgo at andred.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=287135)
 View: https://bugzilla.gnome.org/attachment.cgi?id=287135
 Review: https://bugzilla.gnome.org/review?bug=737412&attachment=287135

codecparser: h264: smash stack corruption bug

Playing back a certain broken stream, causes the following crash on x86_64:

#0  0x00007ffff6f88bb9 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff6f8bfc8 in __GI_abort () at abort.c:89
#2  0x00007ffff6fc5e14 in __libc_message (do_abort=do_abort at entry=1,
fmt=fmt at entry=0x7ffff70d206b "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff705d7dc in __GI___fortify_fail (msg=<optimized out>,
msg at entry=0x7ffff70d2053 "stack smashing detected") at fortify_fail.c:37
#4  0x00007ffff705d780 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x00007fffcadd5944 in gst_h264_parse_process_nal (h264parse=0x7fffc401a6f0,
nalu=0x7fffcb7fd750) at
/home/ad/devel/4646/gst-plugins-bad/gst/videoparsers/gsth264parse.c:715
#6  0x00000000cadd6e00 in ?? ()

Using a well placed breakpoint, we can also see that the pointer to nalu
becomes corrupted in the calling function:

#0  slice_parse_ref_pic_list_modification_1 (slice=0x2effa324, nr=0x2eff9728,
list=0)
    at
/usr/src/debug/gst-plugins-bad/1.4+gitAUTOINC+ae7db18a0b-r0/git/gst-libs/gst/codecparsers/gsth264parser.c:539
#1  0x318d0370 in slice_parse_ref_pic_list_modification (slice=0x2effa324,
nr=0x2eff9728)
    at
/usr/src/debug/gst-plugins-bad/1.4+gitAUTOINC+ae7db18a0b-r0/git/gst-libs/gst/codecparsers/gsth264parser.c:546
#2  0x318da7a8 in gst_h264_parser_parse_slice_hdr (nalparser=0x628008,
nalu=0x2effa934, slice=0x2effa324, 
    parse_pred_weight_table=0, parse_dec_ref_pic_marking=0)
    at
/usr/src/debug/gst-plugins-bad/1.4+gitAUTOINC+ae7db18a0b-r0/git/gst-libs/gst/codecparsers/gsth264parser.c:1771
#3  0x329ef3b8 in gst_h264_parse_process_nal (h264parse=0x475800, nalu=0x0)
    at
/usr/src/debug/gst-plugins-bad/1.4+gitAUTOINC+ae7db18a0b-r0/git/gst/videoparsers/gsth264parse.c:657
#4  0x00000000 in ?? ()

It's OK in frame 2, but not OK in the caller frame 3. This means, that
gst_h264_parse_process_nal() (or functions it calls itself) must have corrupted
it.
One obvious culprit would e.g. be somebody who is overwriting the stack object
'GstH264SliceHdr slice' (from gsth264parse.c gst_h264_parse_process_nal()
around line 655).

Further investigation shows that GstH264SliceHdr::ref_pic_list_modification_l0
and GstH264SliceHdr::ref_pic_list_modification_l1 are arrays with 32 entries
each. The array is written to by slice_parse_ref_pic_list_modification_1() and
indeed, it happens a lot that the while(1) in that function can end up writing
beyond one of the two above arrays, causing stack corruption, and thus the
crash. I have seen it writing into entries > 200, whereas there is space for 32
entries only.

I am not sure if this means there is a bug in the h264 parser, where it doesn't
behave as the spec mandates, or we have a corrupt stream, but attached is a fix
to prevent it from writing into memory that it doesn't own.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.