From 9c5d8c7fd29097d440e8accd1a5055439a47e627 Mon Sep 17 00:00:00 2001 From: Anthony DeRobertis Date: Fri, 3 Jul 2015 00:42:10 -0400 Subject: [PATCH] Fix memory leak with multi-picture FLAC files. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On my music archive, minidlnad wasn't anywhere near through scanning, and had already leaked in excess of 10GiB from this. The basic problem is that song_metadata has one image pointer. When it sees a picture metadata item, it mallocs some space and copies the picture to that, then sets the image pointer. That's all well and good, except FLAC (and some other formats, haven't checked them) allow more than one picture. So on the second picture, it does the same thing—except overwriting the previous pointer, thus leaking it. Simple fix: check if != NULL, ignore picture. Signed-off-by: Justin Maggard --- tagutils/tagutils-flc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tagutils/tagutils-flc.c b/tagutils/tagutils-flc.c index b8f41d4..11bb8be 100644 --- a/tagutils/tagutils-flc.c +++ b/tagutils/tagutils-flc.c @@ -75,6 +75,10 @@ _get_flctags(char *filename, struct song_metadata *psong) break; #if FLAC_API_VERSION_CURRENT >= 10 case FLAC__METADATA_TYPE_PICTURE: + if (psong->image) { + DPRINTF(E_INFO, L_SCANNER, "Ignoring additional image [%s]\n", filename); + break; + } psong->image_size = block->data.picture.data_length; if((psong->image = malloc(psong->image_size))) memcpy(psong->image, block->data.picture.data, psong->image_size);