avformat/matroskadec: Free right buffer on error
Since commit 979b5b89, reverting the Matroska ContentCompression is no longer done inside matroska_parse_frame() (the function that creates AVPackets out of the parsed data (unless we are dealing with certain codecs that need special handling)), but instead in matroska_parse_block(). As a consequence, the data that matroska_parse_frame() receives is no longer always owned by an AVBuffer; it is owned by an AVBuffer iff no ContentCompression needed to be reversed; otherwise the data is independently allocated and needs to be freed on error. Whether the data is owned by an AVBuffer or not is indicated by a variable buf of type AVBufferRef *: If it is NULL, the data is independently allocated, if not it is owned by the underlying AVBuffer (and is used to avoid copying the data when creating the AVPackets). Because the allocation of the buffer holding the uncompressed data happens outside of matroska_parse_frame() (if a ContentCompression needs to be reversed), the data is passed as uint8_t ** in order to not leave any dangling pointers behind in matroska_parse_block() should the data need to be freed: In case of errors, said uint8_t ** would be av_freep()'ed in case buf indicated the data to be independently allocated. Yet there is a problem with this: Some codecs (namely WavPack and ProRes) need special handling: Their packets are only stored in Matroska in a stripped form to save space and the demuxer reconstructs full packets. This involved allocating a new, enlarged buffer. And if an error happens when trying to wrap this new buffer into an AVBuffer, this buffer needs to be freed; yet instead the given uint8_t ** (holding the uncompressed, yet still stripped form of the data) would be freed (av_freep()'ed) which certainly leads to a memleak of the new buffer; even worse, in case the track does not use ContentCompression the given uint8_t ** must not be freed as the actual data is owned by an AVBuffer and the data given to matroska_parse_frame() is not the start of the actual allocated buffer at all. Both of these issues are fixed by always freeing the current data in case it is independently allocated. Furthermore, while it would be possible to track whether the pointer from matroska_parse_block() needs to be reset or not, there is no gain in doing so, as the pointer is not used at all afterwards and the sematics are clear: If the data passed to matroska_parse_frame() is independently allocated, then ownership of the data passes to matroska_parse_frame(). So don't pass the data via uint8_t **. Fixes Coverity ID 1462661 (the issue as described by Coverity is btw a false positive: It thinks that this error can be triggered by ProRes with a size of zero after reconstructing the original packets, but the reconstructed packets can't have a size of zero). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Showing
Please
register
or
sign in
to comment