Heap-buffer-overflow write in FFmpeg SANM process_ftch
It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.
6 records
It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "…
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.
When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.
When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it.
When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer.