Opened 3 years ago

Closed 2 years ago

#8641 closed defect (needs_more_info)

Data race in h264_slice.c and h264dec.c

Reported by: Zu-Ming Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: h264 race
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:

Execute command: ./ffmpeg -y -threads 4 -i small.mp4 output.avi

Version: 4.2

Thread 1:

Race object: h1->is_avc

Access: h->is_avc = h1->is_avc;

Line number: h264_slice.c; 406

Call stack:

  1. ff_h264_update_thread_context()
  2. update_context_from_thread()
  3. submit_packet()
  4. ff_thread_decode_frame()
  5. decode_simple_internal()
  6. decode_simple_receive_frame()
  7. decode_receive_frame_internal()
  8. avcodec_send_packet()
  9. decode()
  10. decode_video()
  11. process_input_packet()
  12. process_input()
  13. transcode_step()
  14. transcode()
  15. main()

Lock: None

Thread 2:

Race object: h->is_avc

Access: h->is_avc = 1;

Line number: h264dec.c; 622

Call stack:

  1. decode_nal_units()
  2. h264_decode_frame()
  3. frame_worker_thread()

Lock: pthread_mutex_lock(&p->mutex);

Impact: This race cause h->is_avc in Thread 1 uncertain, which may affect the status of ffmpeg.

My data race fuzzer, conzzer, finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.

Change History (4)

comment:1 by Zu-Ming, 3 years ago

Keywords: Data race added
Summary: Data race in pthread_frame.c and h264dec.cData race in h264_slice.c and h264dec.c

comment:2 by Carl Eugen Hoyos, 3 years ago

Keywords: h264 added; Data removed
Priority: importantnormal
Version: 4.2unspecified

How can I reproduce the issue?

Please test current FFmpeg git head, the only version supported on this bug tracker.

comment:3 by Zu-Ming, 3 years ago

Thanks for your response, cehoyos.

This race may be hard to reproduce. Actually, this race is detected by a lockset-based algorithm used in my fuzzer. This alogrithm doesn't need the race occurs really in the program. Instead, it uses some runtime information of the program to infer that there are some races in the program. So I just known there is a race in ffmpeg, but haven't idea for reproducing it. To confirm this race, I staitically check the code of ffmpeg, and I think it is a real race.

I test current FFmpeg git head, and I think the race is still alive.

comment:4 by Carl Eugen Hoyos, 2 years ago

Resolution: needs_more_info
Status: newclosed
Note: See TracTickets for help on using tickets.