Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 251160

Summary: [RHEL 5.1] Memory leak in audit tree watch code
Product: Red Hat Enterprise Linux 5 Reporter: Eric Paris <eparis>
Component: kernelAssignee: Alexander Viro <aviro>
Status: CLOSED ERRATA QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 5.0CC: dzickus, eparis, sgrubb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: LSPP
Fixed In Version: RHBA-2007-0959 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-07 19:58:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
script to stress audit tree code
none
proposed fix none

Description Eric Paris 2007-08-07 15:19:54 UTC 
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 15:19:54 UTC 
Created attachment 160817 [details]
script to stress audit tree code
Comment 2 Eric Paris 2007-08-07 15:21:15 UTC 
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 16:19:05 UTC 
/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 16:34:28 UTC 
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 17:34:52 UTC 
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 22:29:14 UTC 
Created attachment 160863 [details]
proposed fix
Comment 9 Don Zickus 2007-08-15 19:05:42 UTC 
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 18:11:16 UTC 
confirmed fix is in the -43 kernel, tested with the attached audit stress script.
Comment 13 errata-xmlrpc 2007-11-07 19:58:07 UTC 
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