Opened 4 years ago

Closed 4 years ago

#1201 closed defect (worksforme)

Write Access Violation

Reported by: daybreak Owned by:
Priority: critical Component: ffplay
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


This is a write access violation within FFPlay.exe.

(cbac.2804): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
* ERROR: Module load completed but symbols could not be loaded for image00000000`00400000
0042b909 0f7f0e movq mmword ptr [esi],mm1 ds:002b:02203000=????????????????
0:000:x86> $<dbgcomm.txt
0:000:x86> !load winext\msec.dll
0:000:x86> !exploitable
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at image00000000_00400000+0x000000000002b909 (Hash=0x67613208.0x0729135c)

User mode write access violations that are not near NULL are exploitable.
0:000:x86> q

mm1 is equal to "0080808000800080" at this point in execution. The attacker has a fair amount of control over the value in esi and this appears to come from offset 0x17dbb8 in the mkv file. This is a write "0080808000800080" anywhere in memory. A clever attacker can use this to create another overflow to achieve code execution or can try to partially overwrite sensitive pointers and other values.

Tested on the shared build from 2012-04-09 found at

PoC file can be downloaded here:

John Villamil

Change History (6)

comment:1 Changed 4 years ago by cehoyos

The sample does not crash here and valgrind does not report any problems.
Is the problem also reproducible with a static ffmpeg build? A static ffplay build? (Or one with debug symbols?)

Does the sample crash on windows with "ffmpeg -i 833694bug669-simpleblocks.mkvtest883.mkv -f null -" or ffplay 833694bug669-simpleblocks.mkvtest883.mkv ?
If yes, please provide a backtrace, consider using a non-stripped binary.

comment:2 Changed 4 years ago by daybreak

This also crashes on the static build from which is from 2012-04-09. This was done on Windows 7 and if there are symbols anywhere I'd be happy to use them.

* ERROR: Module load completed but symbols could not be loaded for image00400000
00b1e849 0f7f0e movq mmword ptr [esi],mm1 ds:002b:06153000=????????????????
0:000> kn

# ChildEBP RetAddr?

WARNING: Stack unwind information not available. Following frames may be wrong.
00 0028fbc8 00b0bb61 image00400000+0x71e849
01 0028fc48 00b009f4 image00400000+0x70bb61
02 0028fcb8 004037b3 image00400000+0x7009f4
03 0028fec8 004013ea image00400000+0x37b3
04 0028ff88 7654339a image00400000+0x13ea
05 0028ff94 77ad9ef2 kernel32BaseThreadInitThunk+0xe
06 0028ffd4 77ad9ec5 ntdll__RtlUserThreadStart+0x70
07 0028ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

comment:3 Changed 4 years ago by ami_stuff

  • Cc added

does it still crashes when you use ffplay -vf scale=320:240 833694bug669-simpleblocks.mkvtest883.mkv?

here sdl window doesn't open at all (zaranoe's build) probably because libsdl doesn't like odd resolutions (width or height) - works fine with -vf scale=320:240

comment:4 Changed 4 years ago by daybreak

It does not crash and plays fine with that argument:
ffplay -vf scale=320:240 833694bug669-simpleblocks.mkvtest883.mkv

comment:5 Changed 4 years ago by ronag

I have the same problem, win64 static build ffplay crashes on win64 with some files, I added two samples in (

I do not have this problem with win32 static build ffplay.

Version 0, edited 4 years ago by ronag (next)

comment:6 Changed 4 years ago by cehoyos

  • Resolution set to worksforme
  • Status changed from new to closed

Does not crash for me with ffmpeg-20120511-git-6d37634-win64-static and ffmpeg-20120511-git-6d37634-win32-static.
Please reopen if you can provide a backtrace or at least command line and complete, uncut console output.

Note: See TracTickets for help on using tickets.