Package: libmagic1
Version: 1:5.22+15-2+deb8u2
Severity: normal

libmagic suffers from a memory leak, apparently due to magic_load()
not satisfying its contract:0

As per man magic_load:
The magic_load() function must be used to load the the colon separated
list of database files passed in as filename, or NULL for the default
database file before any magic queries can performed.

The default database file is named by the MAGIC environment variable.
If that variable is not set, the default database file name is
/usr/share/misc/magic.  magic_load() adds “.mgc” to the database
filename as appropriate.

Steps to reproduce:

$ cat test.c
#include <magic.h>
#include <stdlib.h>

int main ()
{ magic_t _magic = magic_open (MAGIC_MIME); int r = magic_load
(_magic, NULL); magic_close (_magic); }

$ gcc test.c -lmagic
valgrind ./a.out
==30967== Memcheck, a memory error detector
==30967== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30967== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==30967== Command: ./a.out
==30967== HEAP SUMMARY:
==30967== in use at exit: 48 bytes in 3 blocks
==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
==30967== LEAK SUMMARY:
==30967== definitely lost: 48 bytes in 1 blocks
==30967== indirectly lost: 0 bytes in 2 blocks
==30967== possibly lost: 0 bytes in 0 blocks
==30967== still reachable: 0 bytes in 0 blocks
==30967== suppressed: 0 bytes in 0 blocks
==30967== Rerun with --leak-check=full to see details of leaked memory
==30967== For counts of detected and suppressed errors, rerun with: -v
==30967== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

To fix the above, either:
- use "MAGIC=/usr/share/misc/magic valgrind ./a.out"
- or modify the above test code "magic_load (_magic, "/usr/share/misc/magic")

It turns out the private function get_default_magic() returns
"/etc/magic" instead of the document default "/usr/share/misc/magic",
which in turns generates some lost blocks.


Either fix upstream or export the MAGIC environment variable (probably
better / easier considering the code!).

Side notes:
- Reported with details by Michal Vyskocil from the Eaton Opensource Team
- Redhat has a similar ticket which they solved:

Eaton Data Center Automation Solutions - Opensource Leader
NUT (Network UPS Tools) Project Leader -
Debian Developer -
Free Software Developer -

Reply via email to