Bug 251160 - [RHEL 5.1] Memory leak in audit tree watch code
[RHEL 5.1] Memory leak in audit tree watch code
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
high Severity high
: ---
: ---
Assigned To: Alexander Viro
Martin Jenner
LSPP
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-07 11:19 EDT by Eric Paris
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 14:58:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
script to stress audit tree code (4.82 KB, text/plain)
2007-08-07 11:19 EDT, Eric Paris
no flags Details
proposed fix (2.65 KB, patch)
2007-08-07 18:29 EDT, Alexander Viro
no flags Details | Diff

  None (edit)
Description Eric Paris 2007-08-07 11:19:54 EDT
I've got a script which just basically does

while (true)
   auditctl -D
   insert 50 directory watches
done

When run in /proc/slabinfo you can just watch size 32, 64, and 256 slabs fly out
the window and never come back.

watch "grep size /proc/slabinfo | grep -v DMA"

eventually the box ran out of memory and started oomkilling.
Comment 1 Eric Paris 2007-08-07 11:19:54 EDT
Created attachment 160817 [details]
script to stress audit tree code
Comment 2 Eric Paris 2007-08-07 11:21:15 EDT
part of slabinfo after only a few moments.

size-256          135255 135255    256   15    1 : tunables  120   60    8 :
slabdata   9017   9017     60
size-64            26074  26137     64   59    1 : tunables  120   60    8 :
slabdata    443    443     60
size-128          111552 111570    128   30    1 : tunables  120   60    8 :
slabdata   3719   3719     60
size-32           270592 270704     32  112    1 : tunables  120   60    8 :
slabdata   2417   2417     60
Comment 3 Eric Paris 2007-08-07 12:19:05 EDT
/proc/slab_allocators

size-256:       231129  alloc_chunk+0x1f/0x7f
size-256:       22316   audit_make_tree+0x70/0xf0
size-64:        44618   audit_unpack_string+0x3b/0x6f
size-128:       208813  audit_make_tree+0x70/0xf0
size-32:        417496  audit_unpack_string+0x3b/0x6f
Comment 4 Eric Paris 2007-08-07 12:34:28 EDT
at least some of the audit_unpack_string leaks are from alloc_tree() where we do
                strcpy(tree->pathname, s);

but most of the audit code just does tree->pathname = s; and frees it when the
object gets cleaned up.

Comment 5 Alexander Viro 2007-08-07 13:34:52 EDT
Eh?  tree->pathname = s won't compile (it's an array).  But yeah,
we should free the result of audit_unpack_string() unconditionally
there.  It still doesn't account for audit_make_tree() leak or
alloc_chunk() one.  The latter is the consequence of the former,
so the question is WTF do we leak audit_tree there.
Comment 6 Alexander Viro 2007-08-07 18:29:14 EDT
Created attachment 160863 [details]
proposed fix
Comment 9 Don Zickus 2007-08-15 15:05:42 EDT
in 2.6.18-40.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 11 Mike Gahagan 2007-08-30 14:11:16 EDT
confirmed fix is in the -43 kernel, tested with the attached audit stress script.
Comment 13 errata-xmlrpc 2007-11-07 14:58:07 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0959.html

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