Bug 644930 - memory leak in aide
memory leak in aide
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: aide (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Kopeček
BaseOS QE Security Team
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-20 12:02 EDT by Olivier Fourdan
Modified: 2013-04-12 16:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-13 09:04:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
aide configuration file (1.19 KB, text/plain)
2010-10-20 12:02 EDT, Olivier Fourdan
no flags Details
Proposed patch (411 bytes, patch)
2010-10-20 12:07 EDT, Olivier Fourdan
ofourdan: review?
Details | Diff

  None (edit)
Description Olivier Fourdan 2010-10-20 12:02:52 EDT
Created attachment 454601 [details]
aide configuration file

Description of problem:

"aide" leaks the memory allocated for gcry_md_context by md_open() (in libgcrypt) from init_md()

Version-Release number of selected component (if applicable):

aide-0.13.1-6

How reproducible:

Always

Steps to Reproduce:

1. Save the attached aide.conf as /etc/aide.conf
2. Initialize the database

   # aide --init

3. Rename the DB

   # mv /var/lib/aide/aide.db.new  /var/lib/aide/aide.db

4. Run aide in valgrind

   #  valgrind -v --trace-children=yes --tool=memcheck --show-reachable=yes --leak-check=full --leak-resolution=high --log-file=/tmp/valgrind-aide.log aide

5. Check /tmp/valgrind-aide.log

Actual results:

A huge leak is detected

==16149== 1,574,220 bytes in 12,428 blocks are indirectly lost in loss record 185 of 186
==16149==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==16149==    by 0x3020E0928A: do_malloc (global.c:737)
==16149==    by 0x3020E093E8: _gcry_malloc (global.c:759)
==16149==    by 0x3020E1A8EA: md_enable (md.c:588)
==16149==    by 0x3020E1BAE8: _gcry_md_enable (md.c:622)
==16149==    by 0x4050BF: init_md (md.c:221)
==16149==    by 0x40E414: calc_md (do_md.c:177)
==16149==    by 0x40C134: get_file_attrs (gen_list.c:1393)
==16149==    by 0x40A235: db_readline_disk (db_disk.c:244)
==16149==    by 0x40D395: populate_tree (gen_list.c:1509)
==16149==    by 0x41263E: main (aide.c:573)
==16149== 
==16149== 6,181,236 (4,607,016 direct, 1,574,220 indirect) bytes in 4,143 blocks are definitely lost in loss record 186 of 186
==16149==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==16149==    by 0x3020E0928A: do_malloc (global.c:737)
==16149==    by 0x3020E093E8: _gcry_malloc (global.c:759)
==16149==    by 0x3020E1ACB6: md_open (md.c:457)
==16149==    by 0x3020E1AFE3: _gcry_md_open (md.c:530)
==16149==    by 0x405068: init_md (md.c:213)
==16149==    by 0x40E414: calc_md (do_md.c:177)
==16149==    by 0x40C134: get_file_attrs (gen_list.c:1393)
==16149==    by 0x40A235: db_readline_disk (db_disk.c:244)
==16149==    by 0x40D395: populate_tree (gen_list.c:1509)
==16149==    by 0x41263E: main (aide.c:573)

Expected results:

No huge leak.

Additional info:

The leak comes from init_md() which calls md_open() (in libgcrypt's cipher/md.c)

That function allocates a structure gcry_md_context

 453   /* Allocate and set the Context pointer to the private data */
 454   if (secure)
 455     hd = gcry_malloc_secure (n + sizeof (struct gcry_md_context));
 456   else
 457     hd = gcry_malloc (n + sizeof (struct gcry_md_context));
 458 

From valgrind logs, this is this structure which is leaked.

But libgcrypt has a function to free it, it's md_close() available via the function gcry_md_close() (from the public API).

aide do also have a close_md() function which is called once done with the gcry_md_context context (as seen in aide's src/md.c)

The problem is that close_md() from aide does not call gcry_md_close() from libgcrypt, but gcry_md_reset() instead.

And gcry_md_reset() does not free the data, the purpose of that function is actually to allow the reuse of the gcry_md_context. But "aide" does not reuse it, it creates a new one each time in src/do_md.c by calling init_md(), thus the leak...

Using gcry_md_close() instead of gcry_md_reset() in aide's src/md.c does get rid of the leak.
Comment 1 Olivier Fourdan 2010-10-20 12:07:15 EDT
Created attachment 454602 [details]
Proposed patch

Proposed patch based on previous explanation.

Given that init_md() and close_md() are called from the same function calc_md() in src/do_md.c I reckon the structure is not to be reused, so the patch should not break, yet I am not very familiar with aide's code so there could be other problems that I may have not foreseen.
Comment 2 RHEL Product and Program Management 2011-05-31 10:46:46 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 3 Daniel Kopeček 2012-05-03 10:27:24 EDT
This was fixed in rhbz#553137.
Comment 4 Karel Srot 2012-05-03 12:08:33 EDT
Should be fixed already in z-stream package 	aide-0.13.1-6.el5_8.2

> Using gcry_md_close() instead of gcry_md_reset() in 
> aide's src/md.c does get rid of the leak.

The patch regarding bug 553137 is actually calling gcry_md_close() after gcry_md_reset(). I am not sure whether gcry_md_reset() is needed, though.
Comment 5 Karel Srot 2012-07-03 10:12:43 EDT
seems to be really fixed:

aide-0.13.1-6.el5:
==4905==    definitely lost: 1,728,509 bytes in 1,632 blocks
==4905==    indirectly lost: 590,776 bytes in 4,664 blocks

aide-0.13.1-6.el5_8.2:
==4933==    definitely lost: 659 bytes in 84 blocks
==4933==    indirectly lost: 0 bytes in 0 blocks

aide-0.13.1-8.el5
==4952==    definitely lost: 659 bytes in 84 blocks
==4952==    indirectly lost: 0 bytes in 0 blocks

Note You need to log in before you can comment on or make changes to this bug.